Method, system, storage medium, and electronic device for building a container network

Abstract

The present invention relates to a method, system, storage medium and electronic device for building a container network. The system includes a Kubernetes cluster, a CNI plug-in, a resource management system and a cloud platform. The resource management system includes a resource management module, a resource proxy module and an IaaS provider module connected in sequence. The Kubernetes cluster is connected to the CNI plug-in. The resource management module is also connected to the CNI plug-in. The IaaS provider module is connected to the cloud platform. The IaaS provider module is used to connect to the upper cloud platform module through the built-in IaaS provider resource management protocol. Various resource management protocols only provide general description information of resources that are not related to the cloud platform. The capability self-description protocol indicates the network resource management capabilities that the IaaS provider module can provide. In the present invention, the network plug-in is decoupled from the specific cloud platform through the IaaS provider resource management protocol. Only a small amount of corresponding IaaS provider modules are developed to quickly realize the use of the cloud platform VPC network capability Underlay high-performance network plug-in and quickly connect to different cloud platforms.

Description

Technical Field

[0001] The present invention belongs to the technical field of Kubernetes cloud platforms, and specifically relates to a method, system, storage medium, and electronic device for building a container network. Background Art

[0002] The container management platform Kubernetes decouples container network solutions from Kubernetes through the Container Network Interface (CNI), supporting the connection of different container network solutions to meet the needs of different scenarios. Currently, container network solutions can be divided into two categories: Overlay and Underlay. The overlay network solution builds an overlay network based on the existing network environment, often using virtual devices such as veth, bridge, and tun, and packet encapsulation technologies such as ipip and vxlan. In contrast, the underlay container network solution builds a container network on the same network plane based on the existing network environment, often using technologies such as MACVLAN / IPVLAN, sriov, and elastic network cards. Due to the extra layer of abstraction, the overlay container network has different levels of network performance loss.

[0003] The IaaS layer of cloud service providers often uses virtual private clouds (VPCs) to provide network isolation and management capabilities. VPCs can be further divided into subnets or virtual switches (vswitches). Layer 2 connectivity is achieved between VMs within the same subnet, and Layer 3 connectivity is achieved between VMs within the same VPC. VPC network resource management capabilities are provided through APIs, such as dynamically adding network adapters (NICs) to VMs and dynamically binding subnet IP addresses to NICs. Some public cloud service providers, such as AWS's amazon-vpc-cni-k8s plugin and Alibaba Cloud's terway plugin, provide VPC-based underlay container network plug-ins. These implement container networking by dynamically creating NICs and providing them with IP VLAN virtual NICs.

[0004] A Kubernetes pod is the smallest scheduling unit. It contains one or more containers, which share a common network stack. When a pod is created, the kubelet service creates resources such as the pod's network namespace and invokes the container network plugin through the Common Network Interface (CNI) interface. The plugin configures the network stack within the network namespace, enabling interoperability among the containers.

[0005] Some public cloud service providers offer VPC-based Underlay container network plug-ins. These build container networks by dynamically creating network interfaces (NICs) and providing IP VLAN virtual network interfaces (VNICs) for containers. This provides containers with network capabilities comparable to those of the virtual networks in which VMs reside, meeting customer demands for high-performance container networks and VPC-level connectivity. Currently, these VPC-based Underlay container network plug-ins are deeply tied to the cloud platform, preventing cross-cloud use and making them difficult to scale. Furthermore, some public and private cloud providers have not yet implemented similar network plug-ins.

[0006] For example, the high-performance network plugin terway, provided by Alibaba Cloud's container platform (ACK), manages Layer 2 networks using a virtual switch (vswitch). The terway plugin leverages VPC and vswitch capabilities to dynamically create elastic network interfaces (ENIs) and allocate secondary subnet IP addresses for Kubernetes nodes. It configures the container network stack by either exclusively using ENIs or allocating IP VLAN virtual network interfaces. The plugin's logic for managing ENIs and secondary subnet IP addresses is strongly tied to Alibaba Cloud APIs and relies heavily on concepts like Alibaba Cloud ECS metadata and vswitch. This makes the plugin tightly tied to Alibaba Cloud and incapable of running on other cloud platforms. Because the terway plugin's main modules rely to varying degrees on Alibaba Cloud, plugin developers struggle to develop network plugins for other platforms based on it.

[0007] If users rely on network plug-ins that are deeply tied to cloud platforms, differences in these plug-ins can become a constraint when migrating services to other cloud platforms. Furthermore, in private cloud scenarios, given the diverse APIs of private cloud IaaS, there currently isn't a single network plug-in that can quickly connect to various cloud platforms and provide high-performance container networking for the Kubernetes container platform. Summary of the Invention

[0008] In response to the above-mentioned problems existing in the prior art, the present invention provides a method, system, storage medium, and electronic device for building a container network. In the present invention, the network plug-in is decoupled from the specific cloud platform through the IaaS provider resource management protocol. Only a small amount of corresponding IaaS provider module is developed to quickly implement the Underlay high-performance network plug-in that uses the cloud platform VPC network capabilities and quickly connect to different cloud platforms.

[0009] The present invention adopts the following technical solutions:

[0010] A first aspect of an embodiment of the present invention provides a system for building a container network, including a Kubernetes cluster, a CNI plug-in, a resource management system, and a cloud platform. The resource management system includes a resource management module, a resource proxy module, and an IaaS provider module connected in sequence. The Kubernetes cluster is connected to the CNI plug-in. The resource management module is also connected to the CNI plug-in. The IaaS provider module is connected to the cloud platform.

[0011] Resource agent module, used to initialize and configure the IaaS provider module;

[0012] The IaaS provider module is used to connect to the cloud platform through the built-in IaaS provider resource management protocol to obtain the corresponding network resources from the cloud platform. The IaaS provider resource management protocol includes multiple resource management protocols and capability self-description protocols. Each resource management protocol only provides general resource description information that is not related to the cloud platform. The capability self-description protocol indicates the network resource management capabilities that the IaaS provider module can provide;

[0013] The resource management module provides a resource management API for the CNI plug-in to obtain network resources.

[0014] Kubernetes cluster, used to create Pods;

[0015] The CNI plug-in is used to obtain network resources from the resource management module and configure the Pod's network stack based on the obtained network resources.

[0016] As a preferred solution, it also includes an object pool module connected to the resource management module and the resource proxy module respectively;

[0017] The object pool module is used to obtain the idle resources and used resource sets based on the resource usage recorded in the local SQLite database and the network resources obtained by the IaaS provider module. It pools the network card and IP resources through the object pool to maintain a certain amount of idle resources.

[0018] As a preferred solution, in the object pool module, network card and IP resources are pooled through the object pool to maintain a certain amount of idle resources. Specifically:

[0019] When the number of idle resources is higher than the configured high watermark, some idle resources are released through the corresponding IaaS provider resource management protocol. When the number of idle resources is lower than the configured low watermark, some resources are requested through the corresponding IaaS provider resource management protocol.

[0020] As a preferred solution, multiple types of resource management protocols include network card resource management protocol, IP resource management protocol, and VIP resource management protocol.

[0021] As a preferred solution, the network resource management capabilities that can be provided by the IaaS provider module are one or more of multi-NIC capabilities, single NIC multi-IP capabilities, multi-NIC multi-IP capabilities, and VIP capabilities.

[0022] A second aspect of an embodiment of the present invention provides a method for building a container network, based on the system for building a container network provided in the first aspect, including the following steps:

[0023] S1. Initialize the corresponding IaaS provider module according to the configuration;

[0024] S2, the IaaS provider module connects to the cloud platform through the built-in IaaS provider resource management protocol to obtain corresponding network resources from the cloud platform;

[0025] S3, the resource management module provides a resource management API for the CNI plug-in to obtain network resources;

[0026] S4. Kubernetes cluster creates Pods;

[0027] S5. The CNI plug-in obtains network resources from the resource management module and configures the Pod's network stack based on the obtained network resources.

[0028] As a preferred solution, the following steps are further included between step S2 and step S3:

[0029] Based on the resource usage recorded in the local SQLite database and the allocated resources obtained by the IaaS provider module, the idle resources and used resource sets are obtained. The network card and IP resources are pooled through the object pool to maintain a certain amount of idle resources.

[0030] As a preferred solution, network card and IP resources are pooled through object pools to maintain a certain amount of idle resources. Specifically:

[0031] When the number of idle resources is higher than the configured high watermark, some idle resources are released through the corresponding IaaS provider resource management protocol. When the number of idle resources is lower than the configured low watermark, some resources are requested through the corresponding IaaS provider resource management protocol.

[0032] As a preferred solution, in step S3, the resource management module also maintains the association between the Pod and the allocated resources based on the local sqlite database and performs life cycle management of the network resources.

[0033] As a preferred solution, the resource management module performs lifecycle management of network resources, specifically including:

[0034] Regularly check whether the Pod is alive. If it is not alive, actively release related network resources;

[0035] Regularly check whether network resources are valid and report an alarm if invalid.

[0036] A third aspect of an embodiment of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute a method for building a container network as described in the second aspect and any one of the second aspects of the embodiment of the present invention.

[0037] A fourth aspect of an embodiment of the present invention provides an electronic device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to execute a method for building a container network as described in the second aspect and any one of the second aspects of the embodiment of the present invention.

[0038] The beneficial effects of the present invention are:

[0039] The network plug-in in the present invention is decoupled from the specific cloud platform through the IaaS provider resource management protocol. Only a small amount of corresponding IaaS provider module is developed to quickly implement the Underlay high-performance network plug-in that uses the cloud platform VPC network capabilities and quickly connect to different cloud platforms. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0041] Figure 1 This is a schematic diagram of the structure of a system for building a container network according to an embodiment of the present invention;

[0042] Figure 2 It is a structural block diagram of the resource management system of the present invention;

[0043] Figure 3 is an interaction diagram between the IaaS provider resource management protocol and the cloud platform described in the present invention;

[0044] Figure 4 1 is a flow chart of a method for building a container network according to an embodiment of the present invention;

[0045] Figure 5 This is an overall flow chart of a method for building a container network according to an embodiment of the present invention;

[0046] Figure 6is a schematic diagram of the structure of a computer-readable storage medium provided according to an embodiment of the present invention;

[0047] Figure 7 is a schematic structural diagram of an electronic device provided according to an embodiment of the present invention. DETAILED DESCRIPTION

[0048] The following describes the embodiments of the present invention through specific embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through different specific embodiments. The details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the following embodiments and features in the embodiments can be combined with each other unless they conflict.

[0049] Example 1:

[0050] Reference Figure 1 As shown, this embodiment provides a system for building a container network, including a Kubernetes cluster, a CNI plug-in, a resource management system, and a cloud platform. The resource management system includes a resource management module, a resource proxy module, and an IaaS provider module connected in sequence. The Kubernetes cluster is connected to the CNI plug-in. The resource management module is also connected to the CNI plug-in. The IaaS provider module is connected to the cloud platform.

[0051] Resource agent module, used to initialize and configure the IaaS provider module;

[0052] The IaaS provider module is used to connect to the cloud platform through the built-in IaaS provider resource management protocol to obtain the corresponding network resources from the cloud platform. The IaaS provider resource management protocol includes multiple resource management protocols and capability self-description protocols. Each resource management protocol only provides general resource description information that is not related to the cloud platform. The capability self-description protocol indicates the network resource management capabilities that the IaaS provider module can provide;

[0053] The resource management module provides a resource management API for the CNI plug-in to obtain network resources.

[0054] Kubernetes cluster, used to create Pods;

[0055] The CNI plug-in is used to obtain network resources from the resource management module and configure the Pod's network stack based on the obtained network resources.

[0056] It also includes an object pool module connected to the resource management module and the resource proxy module respectively;

[0057] The object pool module is used to obtain the idle resources and used resource sets based on the resource usage recorded in the local SQLite database and the network resources obtained by the IaaS provider module. It pools the network card and IP resources through the object pool to maintain a certain amount of idle resources.

[0058] The present invention, referring to Figure 1 As shown, the core consists of two parts: CNI plug-in and resource management system, which are organized in a Client-Server architecture. The CNI plug-in implements the CNI protocol and, as an executable file, connects to kubernetes. The plug-in provides the ability to prepare the container network stack (cmdAdd), delete the container network stack (cmdDel), and check the container network stack (cmdCheck). The required subnet network card, subnet IP and other resources are obtained through the resource management system. It prepares the container network stack by creating an IPVLAN virtual network card or directly using an elastic network card, configuring container and host routing, and configuring Linux traffic control. The resource management system is responsible for connecting to the VPC-related APIs of cloud platforms such as Alibaba Cloud, AWS, or private clouds built on Openstack. By calling such APIs, it manages resources such as network cards and subnet IPs for Kubernetes cluster nodes. These resources will be used by the CNI plug-in to configure the container network. An example of the core configuration fields of the resource management system is as follows:

[0059] {

[0060] "subnets": ["subnet-id"],

[0061] "iaas_type": "openstack",

[0062] "security_groups": ["sg-id-1"], ......

[0063] }

[0064] The iaas_type field specifies which built-in IaaS provider module to use. IaaS provider modules correspond to cloud platforms one-to-one. The subnets field specifies which subnets to use as Pod subnets. This field value is the subnet ID on cloud platforms such as AWS, Huawei Cloud, and OpenStack, and the vswitch ID on Alibaba Cloud. The security_groups field contains the list of security groups to be bound to dynamically created network interfaces. Additionally, there are other configurations, such as the Kubernetes service network segment and object pool size.

[0065] The modules of resource management system are as follows: Figure 2 As shown:

[0066] Resource management module: Provides a resource management API in grpc mode, maintains the relationship between pods and resources such as network cards and IP addresses, and provides lifecycle management capabilities for such resources.

[0067] Object pool module: Due to the uncertainty of the time required to call the IaaS interface, the object pool is used to pool resources such as network cards and IP addresses, maintain a certain amount of idle resources, and directly allocate idle resources to achieve rapid resource allocation. This accelerates the CNI plug-in to configure the container network and prevents Pod creation from being affected by the long preparation time of the container network stack.

[0068] Resource proxy module: As a glue layer, it creates the corresponding IaaS provider module through the iaas_type field and performs some module initialization and configuration work; IaaS provider module: implements the IaaS provider resource management protocol and connects to different cloud platform APIs.

[0069] To achieve cross-platform compatibility, the CNI plug-in's implementation logic is platform-agnostic, focusing solely on common concepts such as network cards, IP addresses, and routing. The resource management, object pool, and proxy modules of the resource management system rely on highly abstract resources such as network cards and IP addresses, whose resource definitions are independent of specific cloud platforms. All cloud platform dependencies are implemented through the IaaS provider module, which connects to the cloud platform via the IaaS provider resource management protocol.

[0070] Reference Figure 3As shown in the figure, the IaaS provider resource management protocol includes resource management protocols such as network interface card (NIC) management, IP management, and VIP management, as well as capability self-description protocols. The capability self-description protocol describes the capabilities provided by the IaaS provider, such as multiple NICs, multiple IP addresses per NIC, multiple NICs with multiple IP addresses, and VIPs. The resource management module initializes the corresponding management module based on these capability self-descriptions and determines which network resources to allocate. For example, if an IaaS provider module only provides multiple IP addresses per NIC, it must implement the subnet IP management protocol. When the CNI plugin requests resources from the resource management system, it returns IP resources for IP VLANs to the CNI plugin, which then uses the IP VLAN virtual network interface card (NIC) to configure the container network. The data definitions of various resource management protocols contain only common resource information, such as platform-independent information such as the ID identifier, NIC MAC address, subnet CIDR, and gateway. The resource agent module uses these abstract resources for resource management. For example, integrating this system with Alibaba Cloud requires only developing a corresponding IaaS provider module. This module's logic is summarized as follows: It obtains authentication information from configuration files or other means and implements the corresponding resource management protocol functions based on the Alibaba Cloud host metadata service and the Alibaba Cloud SDK. The logic for integrating with OpenStack is similar. The IaaS provider resource management protocol shields differences between cloud service providers, enabling resource management functionality and CNI plugin reuse, ultimately enabling the container networking solution to operate across cloud platforms.

[0071] The specific steps of building a network using the above-mentioned system for building a container network are explained in Example 2.

[0072] Example 2:

[0073] Reference Figure 4 The method for building a container network provided in this embodiment includes the following steps:

[0074] S1. Initialize the corresponding IaaS provider module according to the configuration;

[0075] S2, the IaaS provider module connects to the cloud platform through the built-in IaaS provider resource management protocol to obtain corresponding network resources from the cloud platform;

[0076] S3, the resource management module provides a resource management API for the CNI plug-in to obtain network resources;

[0077] S4. Kubernetes cluster creates Pods;

[0078] S5. The CNI plug-in obtains network resources from the resource management module and configures the Pod's network stack based on the obtained network resources.

[0079] More detailed steps in the method for building a container network in the present invention can be found in Figure 5 As shown, the following steps are included:

[0080] 1. Deployment and initialization:

[0081] a. Kubernetes launches the container network service and creates a core configuration file, which contains two types of information. The first type is common configuration used by the resource management system, such as subnet ID, IaaS type, and security group. The second type is configuration required by the IaaS provider module, such as cloud platform-specific configurations like AKSK.

[0082] b. When each Kubernetes node starts the container network service, it copies the CNI configuration file to a specific directory;

[0083] c. When each Kubernetes node starts the container network service, it copies the CNI plug-in file to a specific directory.

[0084] 2. The resource management system manages network cards, IP addresses, and other resources. Take the "multi-network card, multi-IP" capability provided by the IaaS provider module as an example:

[0085] a. Initialize the corresponding IaaS provider module according to the configuration;

[0086] b. IaaS provider module management network card;

[0087] i. Check whether the host machine has a network card for the required subnet. If not, call the cloud platform interface to add a new network card.

[0088] ii. According to the configured network card, if the number of IPs bound to the network card is close to the limit, call the cloud platform interface to add the required subnet network card;

[0089] c. Object pool management IP resources:

[0090] i. Initialize the object pool and obtain the free and used resource sets based on the resource usage recorded in the local SQLite database and the allocated resources obtained from the IaaS provider;

[0091] ii. When the number of idle resources exceeds the configured high watermark, some idle resources are released through the corresponding IaaS provider's resource management protocol; when the number of idle resources falls below the configured low watermark, some resources are requested through the corresponding IaaS provider's resource management protocol;

[0092] d. The resource management module provides grpc services for the CNI plug-in to obtain resources and maintains the relationship between pods and allocated resources based on the local sqlite database:

[0093] e. The resource management module is responsible for the life cycle management of resources such as IP;

[0094] i. Regularly check whether the Pod is alive. If it is not alive, actively release the relevant resources;

[0095] ii. Regularly check whether resources are valid and report an alarm if invalid; maintain resource usage information.

[0096] 3. The CNI plug-in prepares the container network stack:

[0097] a. Kubernetes creates a Pod. After kubelet prepares parameters such as the container network namespace, it calls the CNI plug-in cmdAdd method to configure the container network stack.

[0098] b. The CNI plug-in calls the resource management system to obtain resources. The type of the resource determines the container network configuration plan. If the resource type is IP, the IPVLAN virtual network card is used as the container network card. Check whether the relevant kernel parameters of the host machine are correct, such as whether ip_forwarding is enabled.

[0099] c. The CNI plug-in adjusts the host network. If an IPVLAN virtual network card is used, it checks whether an IPVLAN transit device already exists in the host network namespace. If not, it creates one and configures a direct route from the container IP address to the IPVLAN transit device to enable the host to directly access the container.

[0100] d. The CNI plug-in configures the container network stack. If an IPVLAN virtual network card is used:

[0101] i. Use the subnet network card corresponding to the host as the parent network card, create an IPVLAN virtual device, add it to the container network namespace and bind the IP address;

[0102] ii. Configure network segment routing and default routing. The default routing gateway is the subnet gateway, which means that containers access IP addresses in different subnets of the same VPC through the gateway. Configure the Linux traffic controller so that traffic accessing Kubernetes services is forwarded by the host.

[0103] e. Return the CNI plug-in configuration result of the container network stack to kubelet and continue the Pod creation process:

[0104] f. The CNI plug-in methods for deleting the container network stack (cmdDel) and checking the container network stack (cmdCheck) are similar.

[0105] Compared with the native open source container network plug-in based on virtual private network of Kubernetes, the present invention has the following advantages and effects:

[0106] The CNI plug-in and the core module of the resource management system are not bound to the cloud platform. They can be connected to different cloud platforms by implementing the IaaS provider resource management protocol. On this basis, the cross-cloud platform feature of the container network plug-in can be realized. This feature can enhance the multi-cloud and multi-scenario adaptability of the Kubernetes container platform, reduce implementation barriers, and improve product competitiveness.

[0107] The CNI plug-in and the resource management system core module are both universally logical and scalable. Based on the design of this invention, it is easy to implement features such as multiple network cards for containers in multiple cloud scenarios, thereby enhancing the competitiveness of container platform products.

[0108] Example 3:

[0109] Reference Figure 6 As shown, an embodiment of the present invention further provides a storage medium having a computer program 601 stored thereon. When executed by a processor, the instructions implement the steps of a method for building a container network in the above embodiment. Those skilled in the art will appreciate that all or part of the processes in the above embodiment method can be implemented by instructing the relevant hardware through a computer program. The program can be stored in a computer-readable storage medium. When executed, the program can include the process of the above embodiment 2.

[0110] The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), a flash memory (Flash Memory), a hard disk drive (HDD) or a solid-state drive (SSD), etc.; the storage medium may also include a combination of the above types of memory.

[0111] Example 4:

[0112] Reference Figure 7 As shown, an embodiment of the present invention further provides an electronic device, which may include a processor 51 and a memory 52, wherein the processor 51 and the memory 52 may be connected via a bus or other means. Figure 7 The bus connection is taken as an example.

[0113] The processor 51 may be a central processing unit (CPU). The processor 51 may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or a combination of the above chips.

[0114] Memory 52, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer executable programs, and modules, such as the corresponding program instructions / modules in the embodiments of the present invention. Processor 51 executes the non-transitory software programs, instructions, and modules stored in memory 52 to perform various processor functions and data processing, thereby implementing the method for building a container network in the second embodiment described above.

[0115] The memory 52 may include a program storage area and a data storage area, wherein the program storage area may store applications required for operating the device and at least one function; the data storage area may store data created by the processor 51, etc. In addition, the memory 52 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 52 may optionally include a memory remotely located relative to the processor 51, and these remote memories may be connected to the processor 51 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0116] The one or more modules are stored in the memory 52 , and when executed by the processor 51 , perform a method for building a container network described in the second embodiment.

[0117] The specific details of the above electronic device can be understood by referring to the corresponding descriptions and effects in Example 2, and will not be repeated here.

[0118] The embodiments described above are merely descriptions of preferred implementations of the present invention and are not intended to limit the scope of the present invention. Without departing from the design spirit of the present invention, various modifications and improvements made to the technical solutions of the present invention by ordinary technicians in this field should fall within the scope of protection of the present invention.

Claims

1. A system for building a container network, characterized in that: It includes a Kubernetes cluster, a CNI plug-in, a resource management system, and a cloud platform. The resource management system includes a resource management module, a resource proxy module, and an IaaS provider module, which are connected in sequence. The Kubernetes cluster is connected to the CNI plug-in, the resource management module is also connected to the CNI plug-in, and the IaaS provider module is connected to the cloud platform. Resource agent module, used to initialize and configure the IaaS provider module; The IaaS provider module is used to connect to the cloud platform through the built-in IaaS provider resource management protocol to obtain the corresponding network resources from the cloud platform. The IaaS provider resource management protocol includes multiple resource management protocols and capability self-description protocols. Each resource management protocol only provides general resource description information that is not related to the cloud platform. The capability self-description protocol indicates the network resource management capabilities that the IaaS provider module can provide; The resource management module provides a resource management API for the CNI plug-in to obtain network resources. Kubernetes cluster, used to create Pods; The CNI plug-in is used to obtain network resources from the resource management module and configure the Pod's network stack based on the obtained network resources; It also includes an object pool module connected to the resource management module and the resource proxy module respectively; The object pool module is used to obtain the idle resources and used resource sets based on the resource usage recorded in the local SQLite database and the network resources obtained by the IaaS provider module. It pools the network card and IP resources through the object pool to maintain a certain amount of idle resources.

2. A system for building a container network according to claim 1, characterized in that: In the object pool module, network card and IP resources are pooled through the object pool to maintain a certain amount of idle resources. Specifically: When the number of idle resources is higher than the configured high watermark, some idle resources are released through the corresponding IaaS provider resource management protocol. When the number of idle resources is lower than the configured low watermark, some resources are requested through the corresponding IaaS provider resource management protocol.

3. A system for building a container network according to claim 1, characterized in that: Various resource management protocols include network card resource management protocol, IP resource management protocol, and VIP resource management protocol.

4. A system for building a container network according to claim 1, characterized in that: The network resource management capabilities that the IaaS provider module can provide are one or more of multi-NIC capabilities, single NIC multi-IP capabilities, multi-NIC multi-IP capabilities, and VIP capabilities.

5. A method for building a container network, based on the system for building a container network according to any one of claims 1 to 4, characterized in that: Including steps: S1. Initialize the corresponding IaaS provider module according to the configuration; S2, the IaaS provider module connects to the cloud platform through the built-in IaaS provider resource management protocol to obtain corresponding network resources from the cloud platform; S3, the resource management module provides a resource management API for the CNI plug-in to obtain network resources; S4. Kubernetes cluster creates Pods; S5. The CNI plug-in obtains network resources from the resource management module and configures the Pod's network stack based on the obtained network resources.

6. A method for building a container network according to claim 5, characterized in that: The following steps are included between step S2 and step S3: Based on the resource usage recorded in the local SQLite database and the allocated resources obtained by the IaaS provider module, the idle resources and used resource sets are obtained. The network card and IP resources are pooled through the object pool to maintain a certain amount of idle resources.

7. A method for building a container network according to claim 6, characterized in that: The network card and IP resources are pooled through the object pool to maintain a certain amount of idle resources. Specifically: When the number of idle resources is higher than the configured high watermark, some idle resources are released through the corresponding IaaS provider resource management protocol. When the number of idle resources is lower than the configured low watermark, some resources are requested through the corresponding IaaS provider resource management protocol.

8. A method for building a container network according to claim 5, characterized in that: In step S3, the resource management module also maintains the association between Pods and allocated resources based on the local SQLite database and performs lifecycle management of network resources.

9. A method for building a container network according to claim 8, characterized in that: The resource management module performs lifecycle management of network resources, specifically including: Regularly check whether the Pod is alive. If it is not alive, actively release related network resources; Regularly check whether network resources are valid and report an alarm if invalid.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the method for building a container network according to any one of claims 5 to 9.

11. An electronic device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method for building a container network according to any one of claims 5 to 9 by executing the computer instructions.

Images