A method and system for multi-network card IP address management based on a container cloud platform

Abstract

The application provides a method and system for multi-network card IP address management based on a container cloud platform. A CNI controller is deployed on each node of the container cloud platform to call a plurality of CNI plugins, wherein at least two CNI plugins supporting an Underlay network mode are included; when a request for network configuration of a container group is received, the CNI controller parses a resource file corresponding to the container group to obtain identification information of a plurality of network accessory resource files; and according to the order of the identification information of the plurality of network accessory resource files, the CNI controller successively calls the plurality of CNI plugins to create virtual network cards for the container group; after the virtual network cards are created, the CNI plugin selects an IP address in an unassigned state from an IP address pool corresponding to the virtual network card to assign the IP address to the virtual network card, and different IP address pools belong to different independent subnets. Thus, the IP addresses belonging to different subnets can be assigned to the multiple virtual network cards running in the Underlay mode of the same container group, so that the container group can simultaneously access multiple Underlay subnets.

Description

Technical Field

[0001] This application relates to the field of container cloud platform technology, and in particular to a method, system, computer-readable storage medium, and electronic device for managing multiple network interface card (NIC) IP addresses based on a container cloud platform. Background Technology

[0002] CNI (Container Network Interface) plugins are a set of programs that implement the CNI specification to allocate network resources such as IP addresses to container groups when they are created, and to release the network resources such as IP addresses that the container groups occupy when they are deleted.

[0003] When a container cloud platform (such as a Kubernetes cluster) creates a container group, it uses a CNI plugin to allocate network resources such as IP addresses to the created container group (Pod) to enable communication between container groups.

[0004] Depending on the network mode, CNI plugins can be divided into two types: Underlay network mode and Overlay network mode. Underlay network, also known as physical network, allows container groups on each node to communicate directly via the underlying physical network. Overlay network, on the other hand, is a logical network built on top of the physical network. Container cloud platforms use the Overlay network to separate control and forwarding, thereby virtualizing the physical network. In Overlay mode, container groups communicate via tunnels established between nodes.

[0005] With the development of container technology, business needs have become increasingly complex. In some scenarios, in order to isolate networks with different functions, it is necessary to create multiple virtual network interfaces for container groups. Each virtual network interface connects to different subnets to receive relevant data packets.

[0006] Typically, container groups running on an Underlay network can achieve higher communication performance. However, due to the complexity of virtual network interface card (NIC) management in Underlay mode, existing CNI plugins cannot flexibly manage multiple virtual NICs in Underlay mode, nor can they effectively assign IP addresses belonging to different subnets to different virtual NICs in a container group. This leads to frequent IP address conflicts in multi-NIC container groups in Underlay mode, which in turn makes it impossible to achieve effective isolation and fine-grained management of data traffic.

[0007] Therefore, there is a need to provide an improved technical solution that addresses the shortcomings of the existing technology. Summary of the Invention

[0008] The purpose of this application is to provide a method, system, computer-readable storage medium, and electronic device for managing multiple network interface card (NIC) IP addresses based on a container cloud platform, so as to solve or alleviate the problems existing in the prior art.

[0009] To achieve the above objectives, this application provides the following technical solution:

[0010] This application provides a method for managing multiple network interface card (NIC) IP addresses based on a container cloud platform. Each node of the container cloud platform is deployed with a CNI controller, which can call multiple CNI plugins, including at least two CNI plugins that support Underlay network mode. The method includes:

[0011] In response to receiving a request to configure the network for a container group, the CNI controller parses the resource file corresponding to the container group to obtain identification information of multiple network attachment resource files from the tag field of the resource file corresponding to the container group; the network attachment resource files are used to define the configuration information required to create a virtual network interface card, and the configuration information includes the identification information of the CNI plugin used to create the virtual network interface card;

[0012] The CNI controller, based on the sorting of the identification information of the multiple network attachment resource files, sequentially calls multiple CNI plugins to create the virtual network interface for the container group;

[0013] In response to the completion of the virtual network interface card (NIC) creation, the CNI plugin selects an unassigned IP address from the IP address pool corresponding to the virtual NIC and assigns it to the virtual NIC; wherein different IP address pools belong to different subnets, and different subnets are network isolated from each other, and the IP address pool includes at least one unassigned IP address.

[0014] In the above technical solution, the virtual network interface card (NIC) of the container group includes a primary NIC and at least one secondary NIC. The CNI controller, based on the sorting of the identification information of the multiple network accessory resource files, sequentially calls multiple CNI plugins to create corresponding virtual NICs for the container group, specifically as follows:

[0015] The CNI controller calls the corresponding CNI plugin to create the main network interface for the container group according to the identification information of the network accessory resource file marked with the main network interface identifier in the tag field;

[0016] The CNI controller sequentially calls multiple CNI plugins to create corresponding secondary network cards for the container group according to the sorting of the identification information of the network attachment resource files recorded in the tag field.

[0017] In the above technical solution, the virtual network interface card (NIC) field of the network attachment definition resource file is used to record the identification information of the virtual NIC, and the CNI plugin field is used to record the identification information of the CNI plugin used to create the virtual NIC. The CNI controller calls the CNI plugin according to the identification information of the network attachment resource file through the following steps:

[0018] The CNI controller parses the network attachment resource file based on the identification information of the network attachment resource file, so as to determine the corresponding CNI plugin according to the identification information of the CNI plugin;

[0019] The CNI controller executes the binary file of the CNI plugin to call the CNI plugin to create the virtual network interface card for the container group.

[0020] In the above technical solution, the container cloud platform also deploys an address pool management component, which includes an address pool controller for managing the subnet and the IP address pool.

[0021] Correspondingly, before the CNI controller parses the resource file corresponding to the container group, the following steps are also included:

[0022] The address pool controller creates multiple subnets based on the subnet resource file;

[0023] The address pool controller creates at least one IP address pool under the corresponding subnet according to the address pool resource file.

[0024] In the above technical solution, the address pool management component further includes an address pool proxy, which is used to allocate IP addresses to each of the virtual network interface cards in the container group;

[0025] Correspondingly, the CNI plugin selects an unassigned IP address from the IP address pool corresponding to the virtual network interface card and assigns it to the virtual network interface card, specifically:

[0026] The CNI plugin sends an instruction to the address pool agent to assign an IP address to the virtual network card;

[0027] In response to receiving the instruction, the address pool proxy determines the IP address pool corresponding to the virtual network interface card by accessing the API-Server component, and selects an unallocated IP address from the IP address pool to allocate to the virtual network interface card;

[0028] In response to the IP address being assigned to the virtual network interface card, the address pool proxy marks the IP address as assigned in the address pool resource file corresponding to the IP address pool.

[0029] In the above technical solution, the CNI controller determines the IP address pool corresponding to the virtual network card through the following steps:

[0030] The CNI controller determines that the virtual network interface card is assigned an IP address by the address pool management component based on the content of the IP address allocation field in the network attachment resource file.

[0031] The CNI controller determines the IP address pool corresponding to the virtual network interface card based on the content and format recorded in the tag field of the resource file corresponding to the container group; the tag field records the identification information of the virtual network interface card and the identification information of the IP address pool in the form of a key-value pair set array.

[0032] In the above technical solution, the CNI controller determines the IP address pool corresponding to the virtual network card through the following steps:

[0033] The CNI controller determines the IP address allocation mode as IP address pool mode based on the content recorded in the IP address allocation field of the network attachment resource file, as well as the identification information of the IP address pool corresponding to the virtual network card.

[0034] This application provides a system for managing multiple network interface card (NIC) IP addresses based on a container cloud platform. Each node of the container cloud platform is deployed with a CNI controller, which can call multiple CNI plugins, including at least two CNI plugins that support Underlay network mode. The system includes:

[0035] The parsing unit is configured to, in response to receiving a request for network configuration of a container group, parse the resource file corresponding to the container group to obtain identification information of multiple network attachment resource files from the tag field of the resource file corresponding to the container group; the network attachment resource file is used to define the configuration information required to create a virtual network interface card, and the configuration information includes the identification information of the CNI plugin used to create the virtual network interface card;

[0036] The creation unit is configured such that the CNI controller sequentially calls multiple CNI plugins to create the virtual network interface for the container group based on the sorting of the identification information of multiple network attachment resource files;

[0037] The allocation unit is configured to, in response to the completion of the creation of the virtual network interface card (NIC), select an unallocated IP address from the IP address pool corresponding to the virtual NIC and allocate it to the virtual NIC; wherein, different IP address pools belong to different subnets, and the different subnets are network isolated from each other, and the IP address pool includes at least one unallocated IP address.

[0038] Beneficial effects:

[0039] In the technical solution provided in this application, a CNI controller is deployed on each node of the container cloud platform. This CNI controller can call multiple CNI plugins to create virtual network interfaces for container groups. Among the multiple CNI plugins, at least two support the Underlay network mode. When a request for network configuration of the container group is received, the CNI controller parses the resource file corresponding to the container group to obtain the identification information of multiple network attachment resource files from the label field (i.e., annotation field) of the resource file. The network attachment resource files are used to define the configuration information required to create virtual network interfaces. This configuration information includes the identification information of the CNI plugins used to create virtual network interfaces. After obtaining the identification information of multiple network attachment resource files, the CNI controller calls multiple CNI plugins sequentially to create virtual network interfaces for the container group according to the order of the identification information of the multiple network attachment resource files. After the virtual network interface is created, the CNI plugin also selects an unassigned IP address from the IP address pool corresponding to the virtual network interface and assigns it to the virtual network interface. Different IP address pools belong to different subnets, and different subnets are network isolated from each other. The IP address pool should include at least one unassigned IP address. Therefore, by introducing a CNI controller to call multiple CNI plugins to create virtual network interfaces for container groups, multiple virtual network interfaces can be added to a single container group flexibly and efficiently. After the virtual network interface is created, an unassigned IP address is selected from the IP address pools belonging to different independent subnets corresponding to that virtual network interface and assigned to it, so that the IP addresses of different virtual network interfaces in the same container group belong to different independent subnets. In addition, since the multiple CNI plugins called include at least two CNI plugins that support Underlay network mode, the virtual network interfaces of the container group include at least two virtual network interfaces that support Underlay network mode. Through the above technical solution, unassigned IP addresses under different subnets can be assigned to each virtual network interface in Underlay network mode. This not only achieves isolation between different functional networks, but also optimizes IP address management, avoids IP address conflicts, and achieves flexible and efficient management of virtual network interfaces in Underlay network mode. Attached Figure Description

[0040] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. Wherein:

[0041] Figure 1 This is a logical diagram illustrating how the Kubelet component creates and configures a single virtual network interface for a container group in related technologies.

[0042] Figure 2 This is a logical diagram illustrating the creation of multiple virtual network interface cards (NICs) for a container group according to some embodiments of this application;

[0043] Figure 3 This is a logical diagram illustrating multi-NIC IP address management according to some embodiments of this application;

[0044] Figure 4 This is a flowchart illustrating a method for managing multiple network interface card (NIC) IP addresses based on a container cloud platform, according to some embodiments of this application.

[0045] Figure 5 This is a schematic diagram of the structure of a system for managing multiple network interface card (NIC) IP addresses based on a container cloud platform, according to some embodiments of this application.

[0046] Figure 6 This is a schematic diagram of the structure of an electronic device provided according to some embodiments of this application;

[0047] Figure 7 This is a hardware structure diagram of an electronic device provided according to some embodiments of this application. Detailed Implementation

[0048] To facilitate understanding of the technical solution of this application, the relevant concepts are explained below.

[0049] Container technology is a technology that divides hardware resources into isolated groups, enabling these isolated groups to balance conflicting hardware resource usage needs. In cloud-native scenarios, a lightweight PaaS platform that unifies the orchestration of containers is called a container cloud platform.

[0050] Container cloud platforms, exemplified by Kubernetes clusters, offer a range of functionalities including resource scheduling, service orchestration, application deployment, monitoring and logging, configuration management, storage and network management, and platform security. Deploying business applications within a container cloud platform essentially means deploying them within container groups (Pods). A container group consists of a single container or multiple tightly coupled containers and is the smallest deployable unit in a container cloud platform. A container group contains at least one application container, and in some cases, multiple containers. Furthermore, a container group is configured with storage resources, a unique network IP address, and options that determine how the container group should operate.

[0051] The CNI specification, also known as the Container Network Interface specification, consists of a set of specifications and libraries for configuring the network interface of Linux containers, including the network allocation interface and the network resource release interface.

[0052] CNI plugins are a set of programs that implement the CNI specification and are used to allocate network resources such as IP addresses to container groups when they are created, and to release the network resources such as IP addresses that the container groups occupy when they are deleted.

[0053] Network mode refers to the way containers in different nodes of a container cloud platform connect to each other via a network. Currently, the CNI plugin mainly supports the Underlay network mode and the Overlay network mode.

[0054] CNI plugins that support Overlay mode include Canal, Cilium, Weave, Flannel, and Calico. In Overlay mode, network connectivity between container groups does not rely on the underlying physical network. Instead, tunnels are built between nodes, and when container groups communicate across nodes, the communication data packets are encapsulated into the communication data packets between nodes in the underlying physical network. Container groups on different nodes can use IP addresses from different network segments, thus eliminating concerns about IP address conflicts and simplifying IP address management.

[0055] CNI plugins that support Underlay mode include MacVlan, OVS, and sriov. In Underlay mode, container groups and nodes reside on the same network layer and have the same network status. Network connectivity between container groups relies primarily on the underlying physical network of their respective nodes. Container groups can directly use their own IP addresses for cross-node communication and communication with network devices outside the container cloud platform. Therefore, when managing the IP addresses of container groups in Underlay mode, it is crucial to prevent IP address conflicts between container groups and other container groups or network devices inside or outside the container cloud platform, making IP address management relatively complex.

[0056] While the CNI plugin supports both Underlay and Overlay modes, the two network modes differ significantly in terms of network performance and hardware utilization. Specifically, Overlay mode requires encapsulation of communication data packets, a process that consumes hardware resources and incurs performance losses, leading to reduced hardware utilization and decreased network performance. In contrast, Underlay mode allows containers to communicate directly using their own IP addresses. Therefore, Underlay mode offers better hardware utilization and network performance than Overlay mode, meeting the needs of some business applications where network performance is paramount.

[0057] Furthermore, in certain specific use cases, isolating networks for different business functions is a necessary measure. For example, in a vehicle-to-everything (V2X) system platform deployed on a container cloud platform, the Internet of Things (IoT) connects all transportation equipment, accurately collects traffic flow information using technologies such as image recognition, and controls traffic flow through devices such as traffic lights. The control center of the V2X system monitors and manages all parts of the entire V2X platform. However, the collection of traffic flow information and other data requires low latency to grasp the road and vehicle conditions in real time, while video and image analysis requires high bandwidth to accurately identify road conditions and vehicle information. These two services place different demands on the network performance and bandwidth of their respective container groups. Therefore, transmitting and processing the traffic of these two services through different networks is necessary to meet practical needs.

[0058] To isolate the networks of different business functions in the above scenarios, container cloud platform administrators typically divide the network resources in the container cloud platform into multiple subnets, assigning data collection services to subnet 1 and video image analysis services to subnet 2. Since different subnets cannot communicate directly, the data collection and video image analysis services can be isolated from each other. Similarly, if other services in the vehicle networking system need to be isolated from the data collection and video image analysis services, the container cloud platform administrator only needs to deploy these services in a subnet other than subnet 1 and subnet 2.

[0059] To effectively manage the various functions of the vehicle-to-everything (V2X) system, the control center needs to simultaneously receive feedback from data collection and video image analysis services. One approach is to configure multiple virtual network interface cards (NICs) within the container group housing the control center to receive feedback from different subnets. For example, NIC 1 could be dedicated to receiving feedback from data collection, while NIC 2 could be dedicated to receiving feedback from video image analysis. This method of transmitting feedback from different services via different NICs ensures network isolation between the various services while allowing the control center to access multiple subnets simultaneously.

[0060] Considering performance requirements, the container group where the control center is located should be configured with an Underlay mode virtual network interface card. However, the existing CNI plugins have weak management functions for Underlay mode virtual network interfaces. Compared with a single virtual network interface card running in Underlay mode, after a container group connects to multiple virtual network interfaces, it is more likely that the IP addresses assigned by multiple CNI plugins that support Underlay mode will conflict with other container groups and network devices inside and outside the container cloud platform.

[0061] To this end, this application provides a method, system, computer-readable storage medium, and electronic device for managing multiple network interface cards (NICs) IP addresses based on a container cloud platform. This technical solution introduces a CNI controller to call multiple CNI plugins for network configuration of container groups, thereby supporting the connection of multiple virtual NICs to container groups. By binding each virtual NIC to an IP address pool under a different subnet, it achieves flexible and efficient allocation of IP addresses under different subnets for multiple virtual NICs running in Underlay mode.

[0062] The present application will now be described in detail with reference to the accompanying drawings and embodiments. Various examples are provided by way of interpretation and not by way of limitation. In fact, those skilled in the art will recognize that modifications and variations can be made to the present application without departing from the scope or spirit thereof. For example, a feature shown or described as part of one embodiment may be used in another embodiment to produce yet another embodiment. Therefore, it is desirable that the present application encompass such modifications and variations that fall within the scope of the appended claims and their equivalents.

[0063] Exemplary methods

[0064] This application provides a method for managing multiple network interface card (NIC) IP addresses based on a container cloud platform. Each node of the container cloud platform is deployed with a CNI controller. The CNI controller can call multiple CNI plugins, including at least two CNI plugins that support Underlay network mode. Figures 2-4 As shown, the method includes:

[0065] Step S101: In response to receiving a request to configure the network for the container group, the CNI controller parses the resource file corresponding to the container group to obtain the identification information of multiple network attachment resource files from the tag field in the resource file corresponding to the container group.

[0066] The network attachment resource file is used to define the configuration information required to create a virtual network interface card (NIC). The configuration information includes the identification information of the CNI plugin used to create the virtual NIC.

[0067] In this embodiment of the application, the container cloud platform consists of multiple nodes, and each node is deployed with a node agent component, such as the Kubelet component of the Kubernetes cluster. This component is used to process the tasks issued by the scheduler to the node and manage the lifecycle of the container group, including mounting volumes, container logging, garbage collection and other events related to the container group.

[0068] Figure 1 This illustrates the logical flow of the Kubelet component in related technologies creating and configuring a single virtual network interface card for a container group. For example... Figure 1As shown, after receiving a task from the scheduler to schedule an application instance to its local node, the Kubelet component begins creating a new container group on that node to run the application instance. The Kubelet component invokes the container runtime (e.g., Containerd) by accessing the CRI (Container Runtime Interface) to start the container group. During the container group startup process, the container runtime uses the CNI (Container Network Interface) protocol to call the CNI plugin to configure the network for the container group, specifically configuring the network interface card (NIC) and IP address. After completing the network configuration, the CNI plugin returns the IP allocation result to the Kubelet component.

[0069] In this embodiment, a CNI controller is deployed on each node. The CNI controller on each node calls multiple CNI plugins to create multiple virtual network interfaces (NICs) for the container group on that node and performs corresponding network configurations, enabling the container group to communicate with other container groups in different subnets. That is, unlike the traditional container group startup process, when a request for network configuration of the container group is received, the Kubelet component does not directly call CNI plugins to create virtual NICs. Instead, the CNI controller deployed on each node parses the resource file (YAML or JSON file) corresponding to the container group, obtains the identification information of multiple network attachment resource files from the tag fields in the resource file, and then, based on the configuration information defined in the network attachment resource files for defining the creation of virtual NICs, obtains the identification information of the CNI plugin used to create the virtual NICs, and then calls the corresponding CNI plugin to create the virtual NIC based on the identification information of the CNI plugin.

[0070] Network attachment resources (CRs) are custom resources designed to extend cluster functionality. A CR file is a definition file (CRD) corresponding to a CR. From a program execution perspective, a CR file can be viewed as a definition file for a CR, and a CR is viewed as an instance created based on that file. It should be understood that the CNI controller can create multiple CRs by repeatedly calling the same CR file, i.e., creating multiple instances based on the definition file. Each CR creation process calls the CNI plugin to create a virtual network interface card (NIC). Multiple calls can create multiple CRs for a container group. Therefore, by introducing CRs and the CNI controller to extend cluster functionality, it is possible to easily create multiple CRs for a container group and assign IP addresses belonging to different subnets to each CR, effectively avoiding IP address conflicts.

[0071] Specifically, Figure 2 This illustrates the logical process of the Kubelet component on any node in a Kubernetes cluster creating multiple virtual network interfaces for a container group, such as... Figure 2 As shown, after receiving the task from the scheduler to schedule the application instance to the local node, the Kubelet component begins to execute a series of steps on the local node to start a new container group for running the application instance. When executing the step of configuring the network for the container group, the Kubelet component calls the CNI controller on the local node to configure the network for the container group by sending a network configuration request. After receiving the request to configure the network for the container group, the CNI controller parses the resource file corresponding to the container group and obtains the identification information of multiple network attachment resource files from the tag field of the resource file. These network attachment resource files are used to define the configuration information required to create the virtual network interface card (NIC). The configuration information includes the identification information of the CNI plugins used to create the virtual NIC, such as the name of CNI plugin 1 and the name of CNI plugin 2. Therefore, the CNI controller can determine the multiple CNI plugins to be called (i.e., CNI plugin 1, CNI plugin 2) based on the configuration information, and then the CNI plugins execute the specific steps of creating the virtual NIC based on this configuration information.

[0072] The CNI controller invokes multiple CNI plugins, including at least two that support Underlay network mode. This ensures that at least two of the container group's multiple virtual network interfaces (NICs) operate in Underlay mode. Thus, the CNI controller configures the container group's network by invoking these Underlay-enabled plugins, allowing multiple virtual NICs to be attached to the container group. This enables a single container group to have multiple Underlay-enabled NICs with multiple IP addresses, flexibly and efficiently creating and configuring multiple Underlay-mode virtual NICs. The container group can then communicate with traffic from multiple subnets through these virtual NICs, meeting the network performance requirements of specific application scenarios.

[0073] It should be noted that the identification information of the network attachment resource file recorded in the tag field is used to identify the corresponding network attachment resource file. The content of each network attachment resource file specifically defines the CNI plugin that the CNI controller should call. The identification information of multiple network attachment resource files is separated by a delimiter, which can be a comma or other conventional symbols. This application does not limit this.

[0074] Step S102: The CNI controller sequentially calls multiple CNI plugins to create virtual network cards for the container group based on the sorting of the identification information of multiple network attachment resource files.

[0075] In this embodiment, the ability of the CNI controller to call multiple CNI plugins refers to the CNI controller's ability to call CNI plugins multiple times during the process of configuring the network for the container group. Each time a CNI plugin is called, it creates a virtual network interface card (NIC) for the container group. The CNI plugins called by the CNI controller can be CNI plugins that have been called before or CNI plugins that have never been called before. Taking the creation of three virtual NICs for the container group as an example, the CNI controller can call the MacVlan plugin three times to create three MacVlan virtual NICs for the container group. Alternatively, it can first call the MacVlan plugin to create one MacVlan virtual NIC, then call the IPVlan plugin to create one IPVlan virtual NIC for the container group, and finally call the MacVlan plugin to create another MacVlan virtual NIC. Or, it can first call the IPVlan plugin to create one IPVlan virtual NIC, and then call the MacVlan plugin twice consecutively to create two MacVlan virtual NICs for the container group.

[0076] It should be noted that, based on functionality, CNI plugins can be divided into three categories: main plugins, IPAM plugins, and meta plugins. Main plugins are primarily used to create the binary files for specific network devices, such as bridge (for creating bridge devices), IPvlan, loopback (for creating local loopback (LO) devices), MACvlan, PTP (for creating Veth Pair devices), and VLANs. IPAM plugins are mainly responsible for IP address allocation for container groups, such as DHCP, host-local, and static. Meta plugins are extension plugins that need to be implemented in conjunction with main and IPAM plugins, such as flannel, tuning, portmap, and bandwidth.

[0077] Each CNI plugin is deployed in binary form in the container cloud platform. In the past, the creation of virtual network interfaces for container groups was usually achieved by the Kubelet component calling the binary file of the main plugin, which then executed the configuration process of the virtual network interface. However, since Kubernetes itself does not support calling multiple CNI plugins, even if multiple CNI plugins are configured on each node of the container cloud platform, the Kubelet component can only call the first CNI plugin in alphabetical order to create a virtual network interface for the container group.

[0078] The CNI controller introduced in this application is essentially a meta plugin. It can parse the resource files corresponding to the container group to obtain the identification information of multiple network attachment resource files. Based on the order of the identification information, it calls multiple main plugins to add multiple virtual network interfaces to the container group. Then, the main plugins call the IPAM plugin to allocate IP addresses to the container group based on the configuration information of the network attachment resource files. By introducing the CNI controller, which sequentially calls multiple CNI plugins to create virtual network interfaces for the container group according to the order of the identification information of multiple network attachment resource files, the ability to add multiple virtual network interfaces to the container group is provided.

[0079] In this implementation, the identification information in the identification information of multiple network attachment resource files can be the same or different. That is, the container group can specify the CNI controller to call the corresponding CNI plugin to configure the network based on multiple identical network attachment resource files through the label field, or it can specify multiple different CNI plugins to configure the network information through the label field.

[0080] In scenarios where multiple virtual network interface cards (NICs) are configured in a container group, in some embodiments, the virtual NICs of the container group include a primary NIC and at least one secondary NIC. The CNI controller sequentially calls multiple CNI plugins to create corresponding virtual NICs for the container group based on the sorting of the identification information of multiple network accessory resource files. Specifically, the CNI controller calls the corresponding CNI plugin to create the primary NIC for the container group according to the identification information of the network accessory resource files marked with the primary NIC identifier in the tag field; the CNI controller sequentially calls multiple CNI plugins to create corresponding secondary NICs for the container group according to the sorting of the identification information of the network accessory resource files recorded in the tag field.

[0081] It should be noted that container cloud platforms, represented by Kubernetes, typically adopt a control plane / data plane architecture. A small number of nodes in the cluster are used as control nodes, on which control plane components are deployed to perform cluster management and maintenance tasks. The majority of the remaining nodes are planned as worker nodes, or data plane, to handle business applications.

[0082] In this embodiment, based on the function of the virtual network interface card (NIC), the virtual NICs of the container group are divided into a primary NIC and multiple secondary NICs. The primary NIC is typically used to handle control plane traffic; that is, the primary NIC receives management traffic sent by various control plane components on the container cloud platform control node and reports its own operating status to the control node through the primary NIC, enabling each control component to effectively manage the lifecycle of the container group. The secondary NICs are used to separate data plane traffic; that is, each secondary NIC processes the data traffic of each business application according to its network requirements, ensuring that the traffic of each business application is isolated and does not interfere with each other.

[0083] Specifically, the network accessory resource file used to create the primary network interface card (NIC) can be explicitly specified by setting the corresponding primary NIC identifier in the resource file label field of the container group. This then calls the corresponding CNI plugin to create a primary NIC for the container group that conforms to the configuration information. Alternatively, the primary NIC can be created by the CNI controller using the default CNI plugin based on the pre-set configuration information without explicitly specifying it in the resource file label field. After the primary NIC is created, the container group can interact with various control plane components on the control node, and the container cloud platform can also perceive and manage the container group through the traffic sent by the primary NIC. Subsequently, the CNI controller sequentially calls multiple CNI plugins to create corresponding secondary NICs for the container group according to the sorting of the network accessory resource file identifier information recorded in the label field, so as to separate data plane traffic on the secondary NICs.

[0084] For example, see Figure 2When configuring a container group, a CNI plugin can be selected from multiple plugins to configure and manage the primary network interface (NIC) (e.g., NIC 1). This selected CNI plugin can support either Underlay or Overlay networks. The identifier information of the network accessory resource file corresponding to this CNI plugin is then written into the tag field of the resource file corresponding to the container group, and the corresponding identifier for the primary NIC is set, such as setting the "default-network" identifier in the key-value pair. During container group creation, the CNI controller parses the tag field of the resource file corresponding to the container group and calls the corresponding CNI plugin to create the primary NIC for the container group according to the identifier information of the network accessory resource file marked with the primary NIC identifier in the tag field. Then, the CNI controller sequentially calls multiple CNI plugins to create the corresponding secondary NICs for the container group according to the order of the network accessory resource file identifier information recorded in the tag field.

[0085] Specifically, during the container group creation process, the Kubelet component accesses the CRI to invoke the container runtime to start the container group. During startup, the container runtime uses the CNI protocol to invoke the CNI controller to configure the network for the container group. Based on the tag field of the resource file corresponding to the container group, the CNI controller first invokes the CNI plugin corresponding to the network accessory resource file marked with the primary network interface card (NIC) identifier to create NIC 1 for the container group. Then, according to the identifier information of the next network accessory resource file recorded in the tag field, the CNI controller invokes the CNI plugin to create NIC 2 for the container group, and so on, until all secondary NICs, such as NIC 3, NIC 4, etc., are created sequentially according to the order of the network accessory resource file identifiers recorded in the tag field.

[0086] To extend cluster functionality through network attachment resources and the CNI controller, in some embodiments, the virtual network interface field of the network attachment definition resource file is used to record the identification information of the virtual network interface, and the CNI plugin field is used to record the identification information of the CNI plugin used to create the virtual network interface. The CNI controller invokes the CNI plugin based on the identification information of the network attachment resource file through the following steps: the CNI controller parses the network attachment resource file based on the identification information of the network attachment resource file to determine the corresponding CNI plugin according to the identification information of the CNI plugin; the CNI controller executes the binary file of the CNI plugin to invoke the CNI plugin to create a virtual network interface for the container group.

[0087] In this embodiment, the network attachment definition resource file includes a virtual network interface card (NIC) field and a CNI plugin field. The CNI plugin field records the identification information of the CNI plugin, which points to the CNI plugin that needs to be called to create the virtual NIC. As described above, the CNI controller can call the CNI plugin multiple times. Each time the CNI plugin is called, it will create a virtual NIC for the container group. Multiple calls to the same CNI plugin will create multiple virtual NICs of the same type. In this case, the CNI controller can set a unique identifier for each virtual NIC by adding random characters, sequential numbers, or other methods after the identification information of the virtual NIC, based on the content of the virtual NIC field.

[0088] Specifically, to invoke multiple CNI plugins, the CNI controller first determines the network attachment resource file corresponding to the identifier information recorded in the tag field of the resource file corresponding to the container group. Then, it parses the network attachment resource file, identifies the CNI plugin to be invoked based on the CNI plugin identifier information recorded in the CNI plugin field, and invokes the corresponding CNI plugin binary file stored in the directory based on the CNI plugin identifier information. This binary file is an executable file used to create virtual network interfaces for the container group. During the virtual network interface creation process, a unique identifier is set for each virtual network interface based on the content recorded in the virtual network interface field. Subsequently, the CNI controller attaches the virtual network interface to the container group. In this way, the CNI controller can obtain the identifier information of the invoked CNI plugin from the network attachment resource file and set a corresponding unique identifier for the virtual network interface after the CNI plugin creates it, thereby achieving the creation of multiple virtual network interfaces for the container group at the execution level.

[0089] Step S103: In response to the completion of virtual network card creation, the CNI plugin selects an unassigned IP address from the IP address pool corresponding to the virtual network card and assigns it to the virtual network card.

[0090] Different IP address pools belong to different subnets, and the different subnets are isolated from each other. Each IP address pool includes at least one IP address that is in an unassigned state.

[0091] In this embodiment, both IP address pools and subnets are abstracted as custom resources of the container cloud platform. There is a mapping relationship between subnets and IP address pools. Different IP address pools belong to different subnets, and different subnets are isolated from each other. In this way, by simply assigning unassigned IP addresses in different IP address pools to virtual network interfaces, different virtual network interfaces of a single container group can receive / send data traffic belonging to different subnets. This enables a single container group to easily access multiple isolated networks. Furthermore, since the IP addresses in different IP address pools belong to different subnets, assigning IP addresses to virtual network interfaces based on different IP address pools will not cause IP address conflicts, greatly improving the efficiency of IP address management.

[0092] In some embodiments, the container cloud platform also deploys an address pool management component, which includes an address pool controller for managing subnets and IP address pools. Correspondingly, before the CNI controller parses the resource file corresponding to the container group, the system further includes: the address pool controller creating multiple subnets based on the subnet resource file; and the address pool controller creating at least one IP address pool under the corresponding subnet based on the address pool resource file.

[0093] As explained above, CNI plugins can be functionally divided into main plugins and IPAM plugins. The main plugin creates specific network devices, while IPAM allocates IP addresses to container groups. Some existing CNI plugins include both a main plugin and an IPAM plugin, providing complete container network interface functionality. This means that creating virtual network interfaces and allocating IP addresses to them can be achieved by calling a single CNI plugin. Conversely, some CNI plugins only include a main plugin, lacking the IPAM plugin, but allow the use of third-party IPAM plugins to provide the functionality of allocating IP addresses to container groups. It should be noted that even CNI plugins that include both a main plugin and an IPAM plugin, while providing complete container network interface functionality, still allow the use of third-party IPAM plugins to enhance their ability to allocate IP addresses to container groups.

[0094] In this embodiment, an address pool management component is used instead of the IPAM plugin to assign IP addresses to different virtual network interfaces of the container group.

[0095] Specifically, the address pool management component includes an address pool controller and an address pool agent. The address pool controller manages subnets and IP address pools. The address pool controller can be deployed as a Deployment on any node of the container cloud platform. It can create multiple subnets based on a subnet resource file (also known as a subnet CRD) and create at least one IP address pool under the corresponding subnet based on an address pool resource file (also known as an address pool CRD). The contents of the subnet CRD and address pool CRD can be defined according to the network resource requirements of business applications. The address pool CRD file records the name of the IP address pool, its subnet, the set of available IP addresses under that subnet, the allocated IP addresses, and the network interface cards bound to the allocated IP addresses.

[0096] For example, see Figure 3 The address pool controller is deployed on the control node. The control node also stores subnet CRDs and address pool CRDs. The address pool controller is used to create and maintain multiple subnets based on the subnet CRDs, and to create and maintain at least one IP address pool under the corresponding subnet based on the address pool CRD. Specifically, the address pool controller accesses the API-Server component of the control node to read the contents of the subnet CRD and creates multiple subnets, such as subnet 1 and subnet 2, thereby dividing the cluster's network resources into two isolated subnets. Subsequently, the address pool controller uses the API-Server component to read the contents of the address pool CRD and, based on the configuration information recorded in the address pool CRD, creates multiple IP address pools under the corresponding subnets. For example, IP address pools 1A, 1B, and 1C are created under subnet 1, and IP address pools 2A, 2B, and 2C are created under subnet 2. In this way, by using the address pool controller, combined with the subnet CRD and the address pool CRD, network resources can be divided into multiple subnets, each of which is isolated from each other. Each subnet includes at least one IP address pool. Then, based on the correspondence between virtual network cards and IP address pools recorded in the resource file corresponding to the container group or the network attachment resource file, different virtual network cards of the container group are bound to IP address pools under different subnets, so as to allocate IP addresses of different subnets to different virtual network cards of the container group.

[0097] Based on the address pool controller's management and maintenance of subnets and IP address pools, in order to allocate IP addresses under different subnets to different virtual network interfaces, in some embodiments, the address pool management component also includes an address pool agent. The address pool agent is used to allocate IP addresses to each virtual network interface of the container group. Correspondingly, the CNI plugin selects unassigned IP addresses from the IP address pool corresponding to the virtual network interface and assigns them to the virtual network interface. Specifically, the CNI plugin sends an instruction to the address pool agent to allocate IP addresses to the virtual network interface. In response to receiving the instruction, the address pool agent determines the IP address pool corresponding to the virtual network interface by accessing the API-Server component, and selects unassigned IP addresses from the IP address pool to allocate to the virtual network interface. In response to the IP address being allocated to the virtual network interface, the address pool agent marks the IP address as allocated in the address pool resource file corresponding to the IP address pool.

[0098] In traditional container group IP address allocation, the Kubelet component calls the CNI plugin to allocate IP addresses to the container group. In reality, the Kubelet component calls the main plugin to create a virtual network interface card (NIC), and then the main plugin calls the IPAM plugin to allocate IP addresses to the virtual NIC of the container group.

[0099] In this embodiment, the address pool proxy replaces the IPAM plugin to assign IP addresses to each virtual network interface card in the container group.

[0100] Specifically, after the CNI plugin (specifically the main plugin called by the CNI controller) creates a virtual network interface for the container group, it sends a command to the IPAM plugin to allocate an IP address to that virtual network interface. Upon receiving this command, IPAM does not process it but forwards it to the address pool agent. The address pool agent can be deployed as a Daemonset across all nodes in the container cloud platform. Upon receiving the command to allocate an IP address to the virtual network interface, the address pool agent accesses the API-Server component to determine the IP address pool bound to the virtual network interface from the resource file corresponding to the container group. It then selects an unassigned IP address from this pool and binds it to the virtual network interface, thus allocating the IP address to the virtual network interface. After the IP address is allocated to the virtual network interface, the address pool agent marks it as allocated in the address pool resource file corresponding to the IP address pool.

[0101] To assign IP addresses to different subnets for different virtual network interface cards (NICs), it is necessary to determine the correspondence between virtual NICs and IP addresses of different subnets. To this end, in some embodiments, the CNI controller determines the IP address pool corresponding to the virtual NIC through the following steps: The CNI controller determines that the virtual NIC is assigned an IP address by the address pool management component based on the content of the IP address allocation field in the network attachment resource file; The CNI controller determines the IP address pool corresponding to the virtual NIC based on the content and format recorded in the tag field of the resource file corresponding to the container group; The tag field records the identification information of the virtual NIC and the identification information of the IP address pool in the form of a key-value pair set array.

[0102] In this embodiment, the CNI controller first reads the content of the IP address allocation field (i.e., the IPAM field) of the network attachment resource file. When the content of the IPAM field is: "ipam": {"type": "spiderpool"}, it is determined that the virtual network card is allocated an IP address by the address pool management component. Here, "spiderpool" is the identification information of the address pool management component.

[0103] The CNI controller then reads the tag field from the resource file corresponding to the container group. Based on the content and format of the tag field, it determines the IP address pool corresponding to the virtual network interface card (NIC). The tag field contains the identification information of the virtual NIC and the IP address pool in the form of a key-value pair array. For example, when the tag field contains a key-value pair array with "ippools" as the key and multiple elements representing the correspondence between the virtual NIC's identification information and the IP address pool's identification information, the array corresponding to "ippools" can be read, and each element can be parsed to determine the IP address pool corresponding to the virtual NIC.

[0104] For ease of description, we will take the creation of two virtual network interfaces in a container group as an example. The content of the tag field in the resource file corresponding to the container group is shown in the following example:

[0105] ippools:

[0106] [{"interface":"eth0","ipv4":["v4-ippool1"],"ipv6":["v6-ippool1"]},

[0107] {"interface":"net1","ipv4":["v4-ippool2"],"ipv6":["v6-ippool2"]}];

[0108] In the example above, `interface` represents a virtual network interface card (NIC), and `eth0` and `net1` represent the identification information of the virtual NIC. Here, the identification information uses the name of the virtual NIC; that is, the names of NIC 1 and NIC 2 are `eth0` and `net1`, respectively. The IPv4 and IPv6 address pools corresponding to NIC 1 are `v4-ippool1` and `v6-ippool1`, respectively, and the IPv4 and IPv6 address pools corresponding to NIC 2 are `v4-ippool2` and `v6-ippool2`, respectively. Each virtual NIC's corresponding IP address pool is defined by its respective address pool CRD, such as `v4-ippool1` for NIC 1.

[0109] In the example above, the container group created two virtual network interfaces, NIC 1 and NIC 2, and the tag field in the corresponding resource file of the container group records the IP address pool corresponding to each virtual network interface. It should be understood that when the number of virtual network interfaces in the container group is greater than two, the correspondence between each virtual network interface and the IP address pool is similar to that of two virtual network interfaces, the difference being the number of elements in the key-value pair array. Therefore, the correspondence between multiple virtual network interfaces and the IP address pool will not be elaborated further.

[0110] In addition to recording the correspondence between virtual network interface cards (NICs) and IP address pools in the label field of the container group, in some embodiments, this correspondence can also be recorded in the network attachment resource file. In this case, the CNI controller determines the IP address pool corresponding to the virtual NIC through the following steps: Based on the content recorded in the IP address allocation field of the network attachment resource file, the CNI controller determines that the IP address allocation mode is the IP address pool mode, as well as the identification information of the IP address pool corresponding to the virtual NIC.

[0111] In this embodiment, the IP address allocation field (i.e., the IPAM field) of the network attachment resource file not only records the IP address allocation mode of the virtual network card, but also records the identification information of the IP address pool corresponding to the virtual network card. Therefore, the CNI controller only needs to read the identification information of the network attachment resource file from the tag field of the resource file corresponding to the container group, and then read the content recorded in the IP address allocation field of the network attachment resource file according to the identification information of the network attachment resource file, so as to determine the correspondence between each virtual network card of the container group and the IP address pool.

[0112] Taking the creation of two virtual network interfaces in a container group as an example, the content of the network accessory resource file for network interface 1 is as follows:

[0113] kind:NetworkAttachmentDefinition

[0114] metadata:

[0115] name:default-interface

[0116] spec:

[0117] config:

[0118] '{"IPAM":{"default_ipv4_ippool":["ippool1"],"type":"spiderpool"}....}';

[0119] The following is an example of the content of the network accessory resource file for network card 2:

[0120] kind:NetworkAttachmentDefinition

[0121] metadata:

[0122] name:interface1

[0123] spec:

[0124] config:

[0125] '{"IPAM":{"default_ipv4_ippool":["ippool2"],"type":"spiderpool"}....}';

[0126] The contents of the resource files corresponding to the container group are as follows:

[0127] kind:Pod

[0128] metadata:

[0129] annotation:

[0130] v1.multus-cni.io / default-network:kube-system / default-interface

[0131] k8s.v1.cni.cncf.io / networks:kube-system / interface1;

[0132] In the example above, the identification information of the network accessory resource files corresponding to network interface card 1 and network interface card 2 are default-interface and interface1, respectively. In the IPAM field of both network accessory resource files, default-interface and interface1 are set with "type":"spiderpool", which means that their IP address management is in IP address pool mode. The IP address pool corresponding to default-interface is set to ippool1, and the IP address pool corresponding to interface1 is set to ippool2. The label field of the container group only needs to record the identification information of the network accessory resource file. The CNI controller can determine the correspondence between each virtual network interface card of the container group and the IP address pool based on the identification information of the network accessory resource file. In this way, multiple network interfaces can be bound to IP address pools under multiple subnets.

[0133] Applying the technical solution provided in this application to the aforementioned vehicle networking system, the CNI controller only needs to call multiple CNI plugins to add multiple virtual network cards, such as network card 1 and network card 2, to the container group where the control center is located. Based on the correspondence between network card 1 and network card 2 and a certain IP address pool under subnet 1 and subnet 2 respectively, an IP address in subnet 1 is assigned to network card 1, and an IP address in subnet 2 is assigned to network card 2. This allows network card 1 to access subnet 1 where the data collection service is located, and allows network card 2 to access subnet 2 where the video image service is located, so that the control center of the vehicle networking system can simultaneously receive feedback information from the data collection service and the video image service.

[0134] It should be understood that some traditional CNI plugins can also add multiple virtual network interfaces to a container group. For example, adding network interface 1 to a container group by calling Flannel and adding network interface 2 by calling MacVlan. However, Flannel is a CNI plugin that supports overlay networks and cannot create virtual network interfaces that support underlay networks. Furthermore, because IP address resources are relatively abundant in overlay mode, IP address allocation is less prone to conflicts, and its management is relatively simple. Therefore, when adding multiple virtual network interfaces to a container group using Flannel, there is no need to configure network resources for Flannel; Flannel will automatically create the corresponding IP address pool and assign IP addresses to network interface 1. Although MacVlan is a CNI plugin that supports underlay networks, it is a main plugin and can only create virtual network interfaces. It needs to work with a third-party IPAM plugin for IP address management. However, existing IPAM plugins have weak IP address management capabilities for underlay networks, cannot properly associate IP addresses, and are prone to IP address conflicts, failing to meet the complex IP address management requirements of underlay mode. In other words, directly calling multiple CNI plugins that support Underlay networking in the traditional way to add multiple virtual network interfaces running in Underlay mode to a container group can easily lead to IP address conflicts.

[0135] This application embodiment introduces a CNI controller to call multiple CNI plugins for network configuration of container groups, thereby supporting the addition of multiple virtual network interfaces to the container group. In other words, a single container group can have multiple virtual network interfaces, and thus multiple IP addresses. By setting subnet CRD and address pool CRD, each virtual network interface is bound to an IP address pool under a different subnet. This allows different CNI plugins to configure IP addresses under different subnets for different virtual network interfaces when creating virtual network interfaces for the container group.

[0136] It should be understood that the technical solution of this application embodiment allows multiple CNI plugins to create virtual network cards for the container group, and each plugin sends a request to the IPAM plugin to allocate an IP address to the corresponding virtual network card, thereby allowing virtual network cards created by different CNI plugins to access different subnets, and enabling the container group to access different subnets.

[0137] As a specific example, the method provided in this application embodiment can be executed according to the following specific implementation steps:

[0138] Step 1: After receiving the task from the scheduler to schedule the application instance to the node, the Kubelet component calls the container runtime by accessing the CRI to start the container group;

[0139] Step 2: During container runtime, the CNI controller is invoked via the CNI protocol to configure the network for the container group;

[0140] Step 3: The CNI controller calls the corresponding CNI plugin to add a primary network interface card (NIC) to the container group based on the identification information of the network accessory resource file marked with the primary NIC identifier in the tag field of the resource file corresponding to the container group. The IPAM plugin forwards the request for virtual NIC IP address allocation to the address pool agent. The address pool agent randomly selects an unassigned IP address from the IP address pool corresponding to the primary NIC and configures it as the IP address of the primary NIC.

[0141] Step 4: The CNI controller sequentially calls multiple CNI plugins to create multiple secondary network interfaces for the container group according to the sorting of the identification information of the network attachment resource files recorded in the tag field. The IPAM plugin sequentially forwards the IP address allocation requests of multiple virtual network interfaces to the address pool agent. The address pool agent sequentially selects unassigned IP addresses from the IP address pool corresponding to the multiple secondary network interfaces and sequentially configures them as IP addresses of the multiple secondary network interfaces.

[0142] Step 5: After completing the IP address allocation, the IPAM plugin returns a message indicating successful IP address allocation to the corresponding CNI plugin.

[0143] Step 6: After the container group has started, the container runtime sends a message to the Kubelet component indicating that the container group has started successfully.

[0144] In summary, in this application, a CNI controller is deployed on each node of the container cloud platform. This CNI controller can call multiple CNI plugins to create virtual network interfaces for the container group. Among these multiple CNI plugins, at least two support the Underlay network mode. When a request for network configuration of the container group is received, the CNI controller parses the resource file corresponding to the container group to obtain the identification information of multiple network attachment resource files from the tag field of the resource file. The network attachment resource files are used to define the configuration information required to create the virtual network interface, including the identification information of the CNI plugins used to create the virtual network interface. After obtaining the identification information of the multiple network attachment resource files, the CNI controller calls multiple CNI plugins sequentially to create virtual network interfaces for the container group according to the order of the identification information of the multiple network attachment resource files. After the virtual network interface is created, the CNI plugin also selects an unassigned IP address from the IP address pool corresponding to the virtual network interface and assigns it to the virtual network interface. Different IP address pools belong to different subnets, and different subnets are network isolated from each other. The IP address pool should include at least one unassigned IP address. Therefore, by introducing a CNI controller to call multiple CNI plugins to create virtual network interfaces for container groups, multiple virtual network interfaces can be created for a single container group flexibly and efficiently. After the virtual network interface is created, an unassigned IP address is selected from the IP address pool belonging to different independent subnets corresponding to that virtual network interface and assigned to it, so that the IP addresses of different virtual network interfaces in the same container group belong to different subnets. In addition, since the called CNI plugins include at least two CNI plugins that support Underlay network mode, the virtual network interfaces of the container group include at least two virtual network interfaces that support Underlay network mode. Through the above technical solution, unassigned IP addresses under different subnets can be assigned to each virtual network interface in Underlay network mode. This not only achieves isolation between different functional networks, but also optimizes IP address management, avoids IP address conflicts, and achieves flexible and efficient management of virtual network interfaces in Underlay network mode.

[0145] The technical solution provided in this application embodiment enables container groups with multiple virtual network cards to access multiple subnets simultaneously. This not only utilizes multiple subnets to isolate different business applications, but also ensures that application instances with special requirements can access multiple subnets at the same time, thereby meeting the needs of different business application scenarios and expanding the applicability of configuring multiple network cards in container groups.

[0146] This application provides multiple methods for binding different virtual network cards to IP address pools under different subnets, which can meet the needs of different business scenarios.

[0147] Exemplary System

[0148] This application provides a system for managing multiple network interface card (NIC) IP addresses based on a container cloud platform. Each node of the container cloud platform is deployed with a CNI controller. The CNI controller can call multiple CNI plugins, including at least two CNI plugins that support Underlay network mode. Figure 5 As shown, the system includes: a parsing unit 501, a creation unit 502, and an allocation unit 503. Wherein:

[0149] The parsing unit 501 is configured to, in response to receiving a request for network configuration of the container group, parse the resource file corresponding to the container group to obtain the identification information of multiple network attachment resource files from the tag field of the resource file corresponding to the container group.

[0150] The network attachment resource file is used to define the configuration information required to create a virtual network interface card (NIC). The configuration information includes the identification information of the CNI plugin used to create the virtual NIC.

[0151] Create unit 502 and configure it so that the CNI controller can sequentially call multiple CNI plugins to create virtual network cards for the container group based on the sorting of the identification information of multiple network attachment resource files.

[0152] Allocation unit 503 is configured to, in response to the completion of virtual network interface card (NIC) creation, select an unallocated IP address from the IP address pool corresponding to the virtual NIC and allocate it to the virtual NIC.

[0153] Different IP address pools belong to different subnets, and the different subnets are isolated from each other. Each IP address pool includes at least one IP address that is in an unassigned state.

[0154] The system for managing multiple network interface cards (NICs) IP addresses based on a container cloud platform provided in this application embodiment can implement the steps and processes of the method for managing multiple NICs IP addresses based on a container cloud platform provided in any of the above embodiments, and achieve the same technical effect, which will not be described in detail here.

[0155] Exemplary device

[0156] Figure 6 This is a schematic diagram of the structure of an electronic device provided according to some embodiments of this application; such as Figure 6 As shown, the electronic device includes:

[0157] One or more processors 601;

[0158] A computer-readable medium, configurable to store one or more programs 602, when executed by one or more processors 601, performs the following steps: In response to receiving a request for network configuration of a container group, the CNI controller parses the resource file corresponding to the container group to obtain identification information of multiple network attachment resource files from the tag field of the resource file corresponding to the container group; the network attachment resource file is used to define the configuration information required to create a virtual network interface card (NIC), and the configuration information includes identification information of the CNI plugin used to create the virtual NIC; the CNI controller sequentially calls multiple CNI plugins to create a virtual NIC for the container group according to the sorting of the identification information of the multiple network attachment resource files; in response to the completion of virtual NIC creation, the CNI plugin selects an unassigned IP address from the IP address pool corresponding to the virtual NIC and assigns it to the virtual NIC; wherein different IP address pools belong to different subnets, and different subnets are network isolated from each other, and the IP address pool includes at least one unassigned IP address.

[0159] Figure 7 The hardware structure of an electronic device provided according to some embodiments of this application; such as Figure 7 As shown, the hardware structure of the electronic device may include: a processor 701, a communication interface 702, a computer-readable medium 703, and a communication bus 704.

[0160] The processor 701, communication interface 702, and computer-readable storage medium 703 communicate with each other via communication bus 704.

[0161] Optionally, the communication interface 702 can be an interface of a communication module, such as the interface of a GSM module.

[0162] Specifically, the processor 701 can be configured as follows: In response to receiving a request for network configuration of the container group, the CNI controller parses the resource file corresponding to the container group to obtain the identification information of multiple network attachment resource files from the tag field of the resource file corresponding to the container group; the network attachment resource file is used to define the configuration information required to create a virtual network interface card (NIC), and the configuration information includes the identification information of the CNI plugin used to create the virtual NIC; the CNI controller sequentially calls multiple CNI plugins to create a virtual NIC for the container group according to the sorting of the identification information of the multiple network attachment resource files; in response to the completion of the virtual NIC creation, the CNI plugin selects an unassigned IP address from the IP address pool corresponding to the virtual NIC and assigns it to the virtual NIC; wherein different IP address pools belong to different subnets, and different subnets are network isolated from each other, and the IP address pool includes at least one unassigned IP address.

[0163] The processor 701 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc., or it can be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor.

[0164] The electronic devices described in this application exist in various forms, including but not limited to:

[0165] (1) Mobile communication devices: These devices are characterized by their mobile communication capabilities and primarily aim to provide voice and data communication. These terminals include: smartphones (e.g., iPhones), multimedia phones, feature phones, and low-end phones, etc.

[0166] (2) Ultra-mobile personal computer devices: These devices fall under the category of personal computers, possessing computing and processing capabilities, and generally also have mobile internet access features. These terminals include PDAs, MIDs, and UMPCs, such as the iPad.

[0167] (3) Portable entertainment devices: These devices can display and play multimedia content. This category includes audio and video players (e.g., iPods), handheld game consoles, e-book readers, as well as smart toys and portable car navigation devices.

[0168] (4) Server: A device that provides computing services. The components of a server include a processor, hard disk, memory, system bus, etc. Servers are similar to general computer architectures, but because they need to provide highly reliable services, they have higher requirements in terms of processing power, stability, reliability, security, scalability, and manageability.

[0169] (5) Other electronic devices with data interaction functions.

[0170] It should be noted that, depending on the implementation needs, the various components / steps described in the embodiments of this application can be broken down into more components / steps, or two or more components / steps or parts of the operation of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of this application.

[0171] The methods described in the embodiments of this application can be implemented in hardware, firmware, or as software or computer code that can be stored in a recording medium (such as CD-ROM, RAM, floppy disk, hard disk, or magneto-optical disk), or as computer code downloaded over a network that is originally stored in a remote recording medium or a non-transitory machine storage medium and will be stored in a local recording medium. Thus, the methods described herein can be processed by software stored on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an ASIC or FPGA). It is understood that the computer, processor, microprocessor controller, or programmable hardware includes storage components (e.g., RAM, ROM, flash memory, etc.) capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the method for managing multiple network interface cards (NICs) IP addresses based on a container cloud platform, as described herein, is implemented. Furthermore, when a general-purpose computer accesses the code used to implement the methods shown herein, the execution of the code transforms the general-purpose computer into a dedicated computer for executing the methods shown herein.

[0172] Those skilled in the art will recognize that the units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application of the technical solution and the constraints involved. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0173] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments.

[0174] The device and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0175] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for managing multiple network interface card (NIC) IP addresses based on a container cloud platform, characterized in that, Each node of the container cloud platform is equipped with a CNI controller, which can invoke multiple CNI plugins, including at least two CNI plugins that support the Underlay network mode; the method includes: In response to receiving a request to configure the network for a container group, the CNI controller parses the resource file corresponding to the container group to obtain identification information of multiple network attachment resource files from the tag field of the resource file corresponding to the container group; the network attachment resource files are used to define the configuration information required to create a virtual network interface card, and the configuration information includes the identification information of the CNI plugin used to create the virtual network interface card; The CNI controller, based on the sorting of the identification information of the multiple network attachment resource files, sequentially calls multiple CNI plugins to create the virtual network interface for the container group; In response to the completion of the virtual network interface card (NIC) creation, the CNI plugin selects an unassigned IP address from the IP address pool corresponding to the virtual NIC and assigns it to the virtual NIC; wherein different IP address pools belong to different subnets, and different subnets are network isolated from each other, and the IP address pool includes at least one unassigned IP address.

2. The method for managing multiple network interface card (NIC) IP addresses based on a container cloud platform according to claim 1, characterized in that, The virtual network interface card (NIC) of the container group includes a primary NIC and at least one secondary NIC. The CNI controller, based on the sorting of the identification information of the multiple network accessory resource files, sequentially calls multiple CNI plugins to create corresponding virtual NICs for the container group. Specifically: The CNI controller calls the corresponding CNI plugin to create the main network interface for the container group according to the identification information of the network accessory resource file marked with the main network interface identifier in the tag field; The CNI controller sequentially calls multiple CNI plugins to create corresponding secondary network cards for the container group according to the sorting of the identification information of the network attachment resource files recorded in the tag field.

3. The method for managing multiple network interface card (NIC) IP addresses based on a container cloud platform according to claim 1 or 2, characterized in that, The virtual network interface card (NIC) field in the network attachment resource file is used to record the identification information of the virtual NIC, and the CNI plugin field is used to record the identification information of the CNI plugin used to create the virtual NIC. The CNI controller calls the CNI plugin according to the identification information of the network attachment resource file through the following steps: The CNI controller parses the network attachment resource file based on the identification information of the network attachment resource file, so as to determine the corresponding CNI plugin according to the identification information of the CNI plugin; The CNI controller executes the binary file of the CNI plugin to call the CNI plugin to create the virtual network interface card for the container group.

4. The method for managing multiple network interface card (NIC) IP addresses based on a container cloud platform according to claim 3, characterized in that, The container cloud platform also deploys an address pool management component, which includes an address pool controller. The address pool controller is used to manage the subnet and the IP address pool. Correspondingly, before the CNI controller parses the resource file corresponding to the container group, the following steps are also included: The address pool controller creates multiple subnets based on the subnet resource file; The address pool controller creates at least one IP address pool under the corresponding subnet according to the address pool resource file.

5. The method for managing multiple network interface card (NIC) IP addresses based on a container cloud platform according to claim 4, characterized in that, The address pool management component also includes an address pool agent, which is used to assign IP addresses to each of the virtual network interfaces of the container group. Correspondingly, the CNI plugin selects an unassigned IP address from the IP address pool corresponding to the virtual network interface card and assigns it to the virtual network interface card, specifically: The CNI plugin sends an instruction to the address pool agent to assign an IP address to the virtual network card; In response to receiving the instruction, the address pool proxy determines the IP address pool corresponding to the virtual network interface card by accessing the API-Server component, and selects an unallocated IP address from the IP address pool to allocate to the virtual network interface card; In response to the IP address being assigned to the virtual network interface card, the address pool proxy marks the IP address as assigned in the address pool resource file corresponding to the IP address pool.

6. The method for managing multiple network interface card (NIC) IP addresses based on a container cloud platform according to claim 5, characterized in that, The CNI controller determines the IP address pool corresponding to the virtual network interface card through the following steps: The CNI controller determines that the virtual network interface card is assigned an IP address by the address pool management component based on the content of the IP address allocation field in the network attachment resource file. The CNI controller determines the IP address pool corresponding to the virtual network interface card based on the content and format recorded in the tag field of the resource file corresponding to the container group; the tag field records the identification information of the virtual network interface card and the identification information of the IP address pool in the form of a key-value pair set array.

7. The method for managing multiple network interface card (NIC) IP addresses based on a container cloud platform according to claim 5, characterized in that, The CNI controller determines the IP address pool corresponding to the virtual network interface card through the following steps: The CNI controller determines the IP address allocation mode as IP address pool mode based on the content recorded in the IP address allocation field of the network attachment resource file, as well as the identification information of the IP address pool corresponding to the virtual network card.

8. A system for managing multiple network interface card (NIC) IP addresses based on a container cloud platform, characterized in that, Each node of the container cloud platform is equipped with a CNI controller, which can call multiple CNI plugins, including at least two CNI plugins that support the Underlay network mode. The system includes: The parsing unit is configured to, in response to receiving a request for network configuration of a container group, parse the resource file corresponding to the container group to obtain identification information of multiple network attachment resource files from the tag field of the resource file corresponding to the container group; the network attachment resource file is used to define the configuration information required to create a virtual network interface card, and the configuration information includes the identification information of the CNI plugin used to create the virtual network interface card; The creation unit is configured such that the CNI controller sequentially calls multiple CNI plugins to create the virtual network interface for the container group based on the sorting of the identification information of multiple network attachment resource files; The allocation unit is configured to, in response to the completion of the creation of the virtual network interface card (NIC), select an unallocated IP address from the IP address pool corresponding to the virtual NIC and allocate it to the virtual NIC; wherein, different IP address pools belong to different subnets, and the different subnets are network isolated from each other, and the IP address pool includes at least one unallocated IP address.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method for managing multiple network interface card IP addresses based on a container cloud platform as described in any one of claims 1-7.

10. An electronic device, characterized in that, include: A memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method for managing multiple network interface card (NIC) IP addresses based on a container cloud platform as described in any one of claims 1-7.

Images