Container network architecture, container network configuration method, device and apparatus

CN122601475APending Publication Date: 2026-08-18CHINA MOBILE COMM LTD RES INST +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510175420.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-02-18
Publication Date
2026-08-18

AI Technical Summary

Technical Problem

[0004]本申请实施例提供一种容器网络架构、容器网络配置方法、装置及设备,以解决现有容器网络配置方案接口调用流程较长、端口绑定用时较长,以致网络配置效率较低,无法满足云原生场景中容器敏捷部署的要求的问题

Benefits of technology

[0028] Thus, this application proposes a cloud-native container orchestration network solution based on DPU VF passthrough. The CNI component directly calls the SR-IOV driver in the Host on the CIE node to complete the configuration of the VF type container network interface device, and the CIM updates the network interface address pair information on the PF device through the VIM to generate the enjoyment flow table on the vSwitch. This optimizes the container network port creation and information configuration process, enables the rapid creation and deployment of container network ports, and can meet the needs of agile container deployment in cloud-native scenarios.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122601475A_ABST
    Figure CN122601475A_ABST
Patent Text Reader

Abstract

This application discloses a container network architecture, container network configuration method, apparatus, and device, relating to the field of information technology, to address the problem of low network configuration efficiency in existing solutions. The method includes: creating a container through CIM, starting the container on CIE, and configuring the container's environment parameters; creating a container network namespace through CIE, calling the SR-IOV driver module through CNI in CIE, configuring network ports of multiple VFs, and establishing a mapping relationship between a first VF and the container, where the first VF is any one of the multiple VFs; sending the network port information of the first VF to CIM through CIE; creating a Neutron port through CIM, adding the Neutron port as a sub-interface to the PF main interface, and sending the Neutron port information and PF port information to VIM; and issuing a flow table to vSwitch through VIM, the flow table including the network port information of multiple first VFs, the Neutron port information, and the PF port information. The embodiments of this application optimize the container network port creation and information configuration process, enabling rapid creation and deployment of container network ports.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to a container network architecture, container network configuration method, apparatus and device. Background Technology

[0002] In existing technologies, container network configuration is initiated by network orchestration plugins in the container layer, such as the Container Network Interface (CNI). The main operation is to create virtual network interfaces for containers (pods), including configurations such as Media Access Control (MAC) addresses, Internet Protocol (IP) addresses, and Virtual Local Area Network (VLAN) tags. However, all network interface configuration information is ultimately implemented by the virtualization layer. The CNI calls the Virtualized Infrastructure Manager (VIM) interface to complete the information transfer. The VIM, in collaboration with the Software Defined Networking (SDN) controller, completes the final configuration of the virtual network interface backend on the Data Processing Unit (DPU), as well as the unloading of flow tables for virtual switches (vSwitch).

[0003] However, the above solutions suffer from lengthy interface call processes and port binding times, resulting in low network configuration efficiency and failing to meet the requirements for agile container deployment in cloud-native scenarios. Summary of the Invention

[0004] This application provides a container network architecture, container network configuration method, apparatus, and device to solve the problems of long interface call processes and long port binding times in existing container network configuration schemes, resulting in low network configuration efficiency and failing to meet the requirements of agile container deployment in cloud-native scenarios.

[0005] In a first aspect, embodiments of this application provide a container network architecture, including:

[0006] The system comprises a Container Cluster Manager (CCM), a Container Infrastructure Manager (CIM), a Virtualization Infrastructure Manager (VIM), a Data Processor (DPU), and a Host. The DPU deploys an On-Chip System (SoC), a Virtual Switch (vSwitch), and a Physical Function (PF). The SoC hosts the Neutron network service. The Host deploys a Container Infrastructure Engine (CIE) and a Single Root I / O Virtualization (SR-IOV) driver module. The SR-IOV driver module contains multiple Virtual Functions (VFs) corresponding to the PFs. The CIE contains a Container Network Interface (CNI). The CCM communicates with the VIM, the VIM communicates with the CIM and the SoC, the CIM communicates with the CIE, the CIE communicates with the multiple VFs, the SoC communicates with the vSwitch, the vSwitch communicates with the PF, and the PF communicates with the SR-IOV driver module.

[0007] Secondly, embodiments of this application also provide a container network configuration method, applied to the container network architecture described in the first aspect, the method comprising:

[0008] Perform a first operation and a second operation, wherein the first operation includes:

[0009] A container is created using the CIM, and the container is started on the CIE, with the container's environment parameters configured.

[0010] The container network namespace is created through the CIE, and the SR-IOV driver module is called through the CNI in the CIE to configure the network ports of the multiple VFs and establish a mapping relationship between the first VF and the container, wherein the first VF is any one of the multiple VFs;

[0011] The CIE sends the network port information of the first VF to the CIM;

[0012] The second operation includes:

[0013] The network service Neutron port is created through the CIM, and the Neutron port is added as a sub-interface to the main interface of the PF. The port information of the Neutron and the port information of the PF are sent to the VIM.

[0014] The VIM sends flow tables to the vSwitch on the DPU. The flow tables include network port information of the multiple first VFs, port information of the Neutron, and port information of the PF. The flow tables are used to implement the routing and forwarding of network packets corresponding to the containers.

[0015] Thirdly, embodiments of this application also provide a container network configuration device, configured within the container network architecture described in the first aspect, the container network configuration device comprising:

[0016] An execution module is configured to perform a first operation and a second operation, wherein the first operation includes:

[0017] A container is created using the CIM, and the container is started on the CIE, with the container's environment parameters configured.

[0018] The container network namespace is created through the CIE, and the SR-IOV driver module is called through the CNI in the CIE to configure the network ports of the multiple VFs and establish a mapping relationship between the first VF and the container, wherein the first VF is any one of the multiple VFs;

[0019] The CIE sends the network port information of the first VF to the CIM;

[0020] The second operation includes:

[0021] The network service Neutron port is created through the CIM, and the Neutron port is added as a sub-interface to the main interface of the PF. The port information of the Neutron and the port information of the PF are sent to the VIM.

[0022] The VIM sends flow tables to the vSwitch on the DPU. The flow tables include network port information of the multiple first VFs, port information of the Neutron, and port information of the PF. The flow tables are used to implement the routing and forwarding of network packets corresponding to the containers.

[0023] Fourthly, embodiments of this application also provide an electronic device, including: a transceiver, a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps in the container network configuration method as described in the second aspect.

[0024] Fifthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in the container network configuration method described above.

[0025] Sixthly, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the steps in the container network configuration method described above.

[0026] In this embodiment, the container network architecture includes: a container cluster manager (CCM), a container infrastructure manager (CIM), a virtualization infrastructure manager (VIM), a data processor (DPU), and a host. The DPU deploys an on-chip SoC, a virtual switch (vSwitch), and a physical function (PF). The SoC is equipped with the network service Neutron. The host deploys a container infrastructure engine (CIE) and a single root I / O virtualization (SR-IOV) driver module. The SR-IOV driver module has multiple virtual functions (VFs) corresponding to the PF. The CIE has a container network interface (CNI). The CCM communicates with the VIM. The VIM also communicates with the CIM and the SoC. The CIM communicates with the CIE. The CIE also communicates with the multiple VFs. The SoC communicates with the vSwitch. The vSwitch also communicates with the PF. The PF communicates with the SR-IOV driver module.

[0027] A container is created using the CIM and started on the CIE, configuring its environment parameters. A container network namespace is created using the CIE, and the SR-IOV driver module is called via the CNI in the CIE to configure the network ports of the multiple VFs and establish a mapping relationship between a first VF and the container, where the first VF is any one of the multiple VFs. The network port information of the first VF is sent from the CIE to the CIM. A Neutron port for network service is created using the CIM, and the Neutron port is added as a sub-interface to the main interface of the PF. The port information of the Neutron and the PF is sent to the VIM. A flow table is issued from the VIM to the vSwitch on the DPU. The flow table includes the network port information of the multiple first VFs, the port information of the Neutron, and the port information of the PF. The flow table is used to implement the routing and forwarding of network packets corresponding to the container.

[0028] Thus, this application proposes a cloud-native container orchestration network solution based on DPU VF passthrough. The CNI component directly calls the SR-IOV driver in the Host on the CIE node to complete the configuration of the VF type container network interface device, and the CIM updates the network interface address pair information on the PF device through the VIM to generate the enjoyment flow table on the vSwitch. This optimizes the container network port creation and information configuration process, enables the rapid creation and deployment of container network ports, and can meet the needs of agile container deployment in cloud-native scenarios. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 This is a schematic diagram of the container network architecture provided in an embodiment of this application;

[0031] Figure 2 This is a flowchart of the container network configuration method provided in the embodiments of this application;

[0032] Figure 3 This is a flowchart of the container network configuration based on DPU VF passthrough provided in the embodiments of this application;

[0033] Figure 4 This is a structural diagram of the container network configuration device provided in the embodiments of this application;

[0034] Figure 5 This is a structural diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0035] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0036] To make the embodiments of this application clearer, the relevant technical knowledge involved in the embodiments of this application will be introduced as follows:

[0037] In cloud-native scenarios, bare-metal container deployment is typically used to ensure performance. Therefore, when establishing a container cluster, several bare-metal instances are created in advance through an Infrastructure as a Service (IaaS) resource management platform to serve as compute nodes for deploying the container engine and related orchestration components. In cloud data centers, the management and orchestration of IaaS resource instances such as virtual machines and bare metal instances are implemented under an SDN network architecture. Therefore, to achieve cloud-based management of bare metal instances, DPU cards are typically used on servers instead of traditional ordinary network cards. Cloud platform components such as vSwitch and nova are installed and deployed within the DPU to automate the network configuration of bare metal instances, thereby enabling the management and provisioning of bare metal instances within the cloud data center's SDN network.

[0038] During container cluster deployment, the Container Cluster Manager (CCM) calls the Virtualized Infrastructure Manager (VIM) interface. VIM enables network virtualization components on the DPU, such as Neutron and vSwitch, through Remote Procedure Call (RPC) communication within the virtualized layer. These components complete network configurations for bare metal instances, including virtual network interfaces, enabling the provisioning and launching of bare metal instances. After cluster deployment, successfully provided bare metal instances become container compute nodes, i.e., Container Infrastructure Engines (CIEs). The Container Control Node (CIM) creates corresponding container pods on the CIE nodes based on business deployment requirements, such as container configurations and image files. It then uses the Container Networking Adapter (CNI) plugin to configure the network information of the container pods. CNI also calls the VIM interface to create virtual network interfaces and configure flow tables on the network virtualization components of the DPU.

[0039] In the existing technical solution, each virtual network interface of a container pod corresponds to a virtualized IO network (virtio-net) device, a network service port (neutron port), and a vSwitch port provided by the DPU. All virtual network interfaces of the container are created by the network virtualization component vSwitch on the DPU, and vSwitch is responsible for the transmission of all network data packets between containers.

[0040] As can be seen, in the existing solution, the configuration of the container network is initiated by the Network Orchestration (CNI) plugin in the container layer. The main operation is to create virtual network interfaces for container pods. However, all network interface configuration information is ultimately implemented by the virtualization layer. CNI calls the VIM interface to complete the information transfer, and VIM, in coordination with the SDN controller, completes the final configuration of the virtual network interface backend on the DPU card, vSwitch flow table offloading, and other operations. In this solution, the work of each object is clearly defined, which is in line with the SDN / Network Functions Virtualization (NFV) architecture. However, in cloud-native scenarios, the biggest characteristic of containers is agility, which means that the platform needs to complete container orchestration and network configuration in a very short time. If the existing solution is used, the following problems will exist:

[0041] 1) The interface call process is relatively long: The entire process involves the chaining of multiple entity objects such as CIM-VIM-SDN-DPU, and the call process is serial, with each level receiving parameter information from the previous level.

[0042] 2) Port binding takes a long time: The binding time between the virtio-net device backend created by vSwitch and the pod virtual network port is long (around 10 seconds, about 10 times the time of the front-end application programming interface (API) call), and it increases linearly with the number of ports mounted on the pod.

[0043] In summary, using existing solutions for container network orchestration and configuration in bare-metal container scenarios leads to low network configuration efficiency, negating the advantages of agile container deployment and regeneration in cloud-native environments. Therefore, this application proposes a cloud-native container orchestration network solution based on DPU VF passthrough, optimizing the container network port creation and information configuration process to achieve rapid creation and deployment of container network ports, meeting the agile deployment and regeneration requirements of cloud-native scenarios.

[0044] The container network architecture and container network configuration method provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0045] See Figure 1 , Figure 1 This is a schematic diagram of the container network architecture provided in the embodiments of this application, such as... Figure 1As shown, the container network architecture includes a Container Cluster Manager (CCM), a Container Infrastructure Manager (CIM), a Virtualization Infrastructure Manager (VIM), a Data Processor (DPU), and a Host. The DPU deploys a System on Chip (SoC), a Virtual Switch (vSwitch), and a Physical Function (PF). The SoC has a network service called Neutron. The Host deploys a Container Infrastructure Engine (CIE) and a Single Root I / O Virtualization (SR-IOV) driver module. The SR-IOV driver module has multiple Virtual Functions (VFs) corresponding to the PFs. The CIE has a Container Network Interface (CNI). The CCM communicates with the VIM, the VIM communicates with the CIM and the SoC, the CIM communicates with the CIE, the CIE communicates with the multiple VFs, the SoC communicates with the vSwitch, the vSwitch communicates with the PF, and the PF communicates with the SR-IOV driver module.

[0046] Among them, the Container Cluster Manager (CCM) is a node responsible for managing containers, and the Virtualization Infrastructure Manager (VIM) is the interface for the Virtual Layer Manager. The CCM can call the VIM interface and, through the VIM, collaborate with the SDN controller to complete operations such as configuring the virtual network interface backend on the DPU card and unloading the vSwitch flow table.

[0047] The Container Infrastructure Manager (CIM) is the control node of the container network, and the Container Infrastructure Engine (CIE) is the compute node of the container network. The CIM can control the CIE node to create containers and perform relevant configurations for the container network according to the needs of business deployment.

[0048] A DPU is a chip specifically designed to handle network transmission, data security, and infrastructure tasks in data centers. In this embodiment, an on-chip SoC, vSwitch, and PF can be deployed on the DPU. The Neutron network service is set up on the SoC to establish a communication connection between the VIM and the vSwitch. The vSwitch is responsible for receiving flow tables and performing packet routing and forwarding operations based on the flow tables. The PF can act as the sole port to take over the vSwitch, and can directly forward packets within the same VLAN. It can also be designated as a PF to virtualize a number of VF devices through I / O virtualization technology, which are then implemented in the Host Operating System (OS) as high-speed serial computer extended bus standard (peripheral component interconnect express, PCIe) devices.

[0049] The host machine deploys CIE and SR-IOV driver modules. The SR-IOV driver module is configured with multiple corresponding VFs virtualized by PF. The CIE is configured with a container network interface (CNI). The CNI component is responsible for configuring the VF ports by directly connecting the CIE node to the SR-IOV driver within the host OS.

[0050] Based on the above container network architecture, a cloud-native container orchestration network solution based on DPU VF passthrough can be realized. The CNI component can directly call the SR-IOV driver in the Host to complete the configuration of the VF type container network interface device in the CIE node. The CIM can update the network interface address information on the PF device through the VIM to generate the enjoyment flow table on the vSwitch. This enables the rapid creation and deployment of container network ports, meeting the needs of agile container deployment in cloud-native scenarios.

[0051] based on Figure 1 The container network architecture shown in this application presents a cloud-native container orchestration network solution based on DPU VF passthrough, which enables efficient and agile container network configuration. The following section combines... Figure 2 A detailed introduction will follow.

[0052] See Figure 2 , Figure 2 This is a flowchart of a container network configuration method provided in an embodiment of this application, applied to... Figure 1 The container network architecture shown is as follows: Figure 2 As shown, it includes the following steps:

[0053] Step 201: Perform the first operation and the second operation, wherein the first operation includes:

[0054] S1. Create a container using the CIM, start the container on the CIE, and configure the container's environment parameters;

[0055] S2. Create a container network namespace through the CIE, and call the SR-IOV driver module through the CNI in the CIE to configure the network ports of the multiple VFs, and establish a mapping relationship between the first VF and the container, wherein the first VF is any one of the multiple VFs;

[0056] S3. Send the network port information of the first VF to the CIM through the CIE;

[0057] The second operation includes:

[0058] S4. Create a Neutron port for network service through the CIM, add the Neutron port as a sub-interface to the main interface of the PF, and send the Neutron port information and the PF port information to the VIM;

[0059] S5. The flow table is sent to the vSwitch on the DPU through the VIM. The flow table includes the network port information of the multiple first VFs, the port information of the Neutron and the port information of the PF. The flow table is used to implement the routing and forwarding of network packets corresponding to the container.

[0060] In this embodiment of the application, the VF port and PF port can be configured separately. Specifically, the configuration process of the VF port can be to first create a container POD through CIM, and then start the created container on the CIE through the corresponding scheduling strategy and configure the container-related environment parameters, that is, some environment configuration information that the container needs to use in the Host.

[0061] Next, a container network namespace is created through the CIE, and the SR-IOV driver module in the host OS where the CIE is located is called through the CNI plugin in the CIE to configure the network port information of the multiple VFs, and mount and map the VF devices to the corresponding container PODs, that is, to establish a mapping relationship between one of the multiple VFs and the created container POD.

[0062] After the CIE node completes the creation of the container and the configuration of the VF port information, it can save the container POD network configuration information and return it to the CIM. That is, the CIE can send the configured VF network port information to the CIM.

[0063] The configuration process for the PF port can begin by creating a Neutron port for network services on the DPU's SoC via the CIM, and then adding the Neutron port as a sub-interface to the PF's main interface. That is, the Neutron port and the PF port serve as the sub-interface and parent interface of the trunk network, respectively. After creation, the CIM can synchronize and update the Neutron port information and the PF port information to the VIM. It should be noted that the Neutron port creation step only needs to be performed once after the CIE node is deployed; subsequent POD virtual port creations only require updating the Neutron port address pair information.

[0064] Then, the VIM can work with the SDN controller to send flow tables to the vSwitch forwarding component on the DPU via the OpenFlow protocol. The configured VF port information, Neutron port information and PF port information are sent to the vSwitch through the flow tables. The vSwitch can complete the packet routing and forwarding operation according to the port address information in the flow tables.

[0065] It should be noted that before performing the first and second operations, CIM can also perform relevant preparatory work for container network configuration, such as planning container network information, preparing VF virtual network port pools, planning corresponding VLANs and corresponding Neutron network information for the VIM layer. CIM can maintain this network information in the CNI plugin to prepare for the configuration of VIM and CIE node network ports.

[0066] Optionally, the first operation and the second operation are executed in parallel.

[0067] The first operation described above involves the CNI component directly interfacing with the DPU SR-IOV driver within the CIE node's Host OS to configure the VF port. The second operation described above involves calling VIM to update the PF port information. Each operation takes milliseconds. In this embodiment, the first and second operations can be executed in parallel, thereby significantly reducing the container network configuration time from tens of seconds to milliseconds. This meets the requirements for rapid container deployment and delivery, enabling agile iteration in cloud-native scenarios.

[0068] Optionally, the plurality of VFs are virtualized by the PF through I / O virtualization technology.

[0069] In this embodiment of the application, the DPU can implement the VF pass-through function based on SR-IOV technology, specifying that the PF virtualizes a number of VF devices through I / O virtualization technology, which are manifested in the Host OS as standard PCIe devices. These VF devices are directly managed by the CNI component of the CIE node, and the port configuration of the VF devices is completed through relevant drivers.

[0070] Optionally, configuring the network ports of the plurality of VFs includes:

[0071] Configure the Media Access Control (MAC) address, Internet Protocol (IP) address, and Virtual Local Area Network (VLAN) information of the multiple Virtual Local Area Networks (VFs).

[0072] Specifically, the CNI component of the CIE node can be configured with information such as the MAC address, IP address, and VLAN of the VF device, so that the vSwitch can forward packets based on the port address information and VLAN information of the VF device.

[0073] Optionally, the method further includes:

[0074] The PF is registered by the CIE to take over the port of the vSwitch.

[0075] In some embodiments, the CIM can send a name to the CIE, causing the CIE node to register the PF on the DPU as the unique port to take over the vSwitch, that is, to create the PF as the port of the vSwitch, so that the vSwitch can send and receive messages through the PF port.

[0076] It should be noted that in this embodiment, the vSwitch port creation process only needs to be called once after the bare metal instance (such as a CIE node) is deployed. The subsequent VF port creation operation of all containers is modified to update the vSwitch port address pair (including VF port and PF port information). The upper-layer SDN controller generates and sends the updated flow table to the vSwitch, without the need to implement new port registration and binding.

[0077] In other words, in some embodiments, the method further includes:

[0078] When a new container needs to be created, the network port information of the VF in the flow table is updated, and the updated flow table is sent to the vSwitch through the VIM.

[0079] In other words, when creating a container in the future, you only need to update the VF device port information corresponding to the container created this time in the flow table, and then send the updated flow table to the vSwitch, without having to create the PF port and Neutron port again.

[0080] Optionally, packets communicating between the multiple VFs in the same VLAN are not input to the vSwitch, but are forwarded by the PF;

[0081] Cross-VLAN packets are input to the vSwitch and forwarded by the vSwitch according to the received flow table.

[0082] In some embodiments, the PF device on the DPU can implement a Layer 2 broadcast domain based on VLAN isolation. Packets communicating between all VFs within the same VLAN do not enter the vSwitch component but are directly forwarded by the PF device. Packets crossing VLAN networks enter the vSwitch, where the vSwitch performs routing and forwarding operations based on the generated flow table. This improves packet forwarding efficiency.

[0083] The following is combined Figure 3 Examples illustrate the specific configuration process of embodiments of this application, such as... Figure 3 As shown, the specific steps are as follows:

[0084] 1. Plan container network information, prepare VF virtual network port pool, plan corresponding VLANs and corresponding Neutron network information for VIM layer. CIM maintains this network information in CNI plugin to prepare for VIM and CIE node network port configuration.

[0085] 2. Create a POD. CIM selects a suitable CIE node through the corresponding scheduling strategy, starts the container on the CIE node, and configures the container-related environment variables.

[0086] 3. Create a container network namespace. The CNI plugin calls the SR-IOV driver in the Host OS on the CIE node to configure the VF's MAC, IP, VLAN and other information, and mounts and maps the VF device to the corresponding container POD.

[0087] 4. The CIE node completes the container startup and VF port information configuration, saves the POD network configuration information, and returns it to CIM.

[0088] 5. Create a Neutron port and add it as a sub-interface to the trunk network of the PF main interface (only needs to be performed once after deployment on the CIE node), and update the Neutron port address pair information (this operation only needs to be performed each time a POD virtual port is created thereafter).

[0089] 6. The VIM and SDN controllers work together to distribute flow tables to the vSwitch forwarding component on the DPU via the OpenFlow protocol, enabling network packet routing and forwarding operations at the CIE node.

[0090] In the above process, steps 2, 3, and 4 and steps 5 and 6 can be executed in parallel, with each process operation taking milliseconds.

[0091] In this embodiment of the application, the configuration process includes parallel operations of port configuration and backend configuration. The CNI component directly calls the SR-IOV driver in the Host OS on the CIE node to complete the configuration of the VF type container network interface device. At the same time, the CIM updates the network interface address pair information on the PF device in parallel through the VIM to generate the enjoyment flow table on the vSwitch.

[0092] The DPU virtual network backend includes the collaborative use of the SR-IOV module and the vSwitch module. The SR-IOV module provides VF-type network interface devices for container PODs, enabling VLAN-isolated Layer 2 broadcast domains and completing Layer 2 forwarding between POD network interfaces. The vSwitch module implements a VxLAN-based Layer 3 network, completing Layer 3 forwarding and distributed routing functions between POD network interfaces.

[0093] Compared with existing technologies, the embodiments of this application change the original container network configuration process, splitting the original serial port configuration API call process into a front-end and back-end parallel configuration process. By simplifying the configuration operation, the container network configuration time is significantly reduced from tens of seconds to milliseconds, meeting the requirements for rapid container deployment and enabling agile iteration in cloud-native scenarios. Both the DPU backend SR-IOV and vSwitch technologies are standard technologies; this application simply separates them into container network implementations for different forwarding rules in different scenarios. The technical solution has low complexity and low implementation cost.

[0094] The container network configuration method of this application embodiment involves creating a container through the CIM and starting the container on the CIE, configuring the container's environment parameters; creating a container network namespace through the CIE, and calling the SR-IOV driver module through the CNI in the CIE to configure the network ports of the multiple VFs and establish a mapping relationship between a first VF and the container, wherein the first VF is any one of the multiple VFs; sending the network port information of the first VF to the CIM through the CIE; creating a Neutron port for network services through the CIM, adding the Neutron port as a sub-interface to the main interface of the PF, and sending the Neutron port information and the PF port information to the VIM; and issuing a flow table to the vSwitch on the DPU through the VIM, wherein the flow table includes the network port information of the multiple first VFs, the Neutron port information, and the PF port information, and the flow table is used to implement the routing and forwarding of network packets corresponding to the container. Thus, this application proposes a cloud-native container orchestration network solution based on DPU VF passthrough. The CNI component directly calls the SR-IOV driver in the Host on the CIE node to complete the configuration of the VF type container network interface device, and the CIM updates the network interface address pair information on the PF device through the VIM to generate the enjoyment flow table on the vSwitch. This optimizes the container network port creation and information configuration process, enables the rapid creation and deployment of container network ports, and can meet the needs of agile container deployment in cloud-native scenarios.

[0095] This application embodiment also provides a container network configuration device, set up... Figure 1 The container network architecture shown. See also Figure 4 , Figure 4 This is a structural diagram of the container network configuration device provided in the embodiments of this application. Since the principle of the container network configuration device in solving the problem is similar to that of the container network configuration method in the embodiments of this application, the implementation of the container network configuration device can refer to the implementation of the method, and the repeated parts will not be described again.

[0096] like Figure 4 As shown, the container network configuration device 400 includes:

[0097] Execution module 401 is configured to perform a first operation and a second operation, wherein the first operation includes:

[0098] A container is created using the CIM, and the container is started on the CIE, with the container's environment parameters configured.

[0099] The container network namespace is created through the CIE, and the SR-IOV driver module is called through the CNI in the CIE to configure the network ports of the multiple VFs and establish a mapping relationship between the first VF and the container, wherein the first VF is any one of the multiple VFs;

[0100] The CIE sends the network port information of the first VF to the CIM;

[0101] The second operation includes:

[0102] The network service Neutron port is created through the CIM, and the Neutron port is added as a sub-interface to the main interface of the PF. The port information of the Neutron and the port information of the PF are sent to the VIM.

[0103] The VIM sends flow tables to the vSwitch on the DPU. The flow tables include network port information of the multiple first VFs, port information of the Neutron, and port information of the PF. The flow tables are used to implement the routing and forwarding of network packets corresponding to the containers.

[0104] Optionally, the plurality of VFs are virtualized by the PF through I / O virtualization technology.

[0105] Optionally, configuring the network ports of the plurality of VFs includes:

[0106] Configure the Media Access Control (MAC) address, Internet Protocol (IP) address, and Virtual Local Area Network (VLAN) information of the multiple Virtual Local Area Networks (VFs).

[0107] Optionally, the container network configuration apparatus 400 also includes:

[0108] A registration module is used to register the PF as a port to take over the vSwitch via the CIE.

[0109] Optionally, the container network configuration apparatus 400 also includes:

[0110] The update module is used to update the network port information of the VF in the flow table when a new container needs to be created, and to send the updated flow table to the vSwitch through the VIM.

[0111] Optionally, packets communicating between the multiple VFs in the same VLAN are not input to the vSwitch, but are forwarded by the PF;

[0112] Cross-VLAN packets are input to the vSwitch and forwarded by the vSwitch according to the received flow table.

[0113] Optionally, the first operation and the second operation are executed in parallel.

[0114] The container network configuration device 400 provided in this application embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0115] The container network configuration device 400 of this application embodiment creates a container through the CIM and starts the container on the CIE, configuring the container's environment parameters; creates a container network namespace through the CIE, and calls the SR-IOV driver module through the CNI in the CIE to configure the network ports of the multiple VFs and establish a mapping relationship between a first VF and the container, where the first VF is any one of the multiple VFs; sends the network port information of the first VF to the CIM through the CIE; creates a Neutron port for network service through the CIM, adds the Neutron port as a sub-interface to the main interface of the PF, and sends the Neutron port information and the PF port information to the VIM; and issues a flow table to the vSwitch on the DPU through the VIM. The flow table includes the network port information of the multiple first VFs, the Neutron port information, and the PF port information, and is used to implement the routing and forwarding of network packets corresponding to the container. Thus, this application proposes a cloud-native container orchestration network solution based on DPU VF passthrough. The CNI component directly calls the SR-IOV driver in the Host on the CIE node to complete the configuration of the VF type container network interface device, and the CIM updates the network interface address pair information on the PF device through the VIM to generate the enjoyment flow table on the vSwitch. This optimizes the container network port creation and information configuration process, enables the rapid creation and deployment of container network ports, and can meet the needs of agile container deployment in cloud-native scenarios.

[0116] This application also provides an electronic device. Since the principle by which the electronic device solves the problem is similar to the container network configuration method in this application, the implementation of this electronic device can be found in the implementation of the method, and repeated details will not be described again. Figure 5 As shown, the electronic device according to an embodiment of this application includes:

[0117] Processor 500 is used to read the program from memory 520 and execute the following procedures:

[0118] Perform a first operation and a second operation, wherein the first operation includes:

[0119] A container is created using the CIM, and the container is started on the CIE, with the container's environment parameters configured.

[0120] The container network namespace is created through the CIE, and the SR-IOV driver module is called through the CNI in the CIE to configure the network ports of the multiple VFs and establish a mapping relationship between the first VF and the container, wherein the first VF is any one of the multiple VFs;

[0121] The CIE sends the network port information of the first VF to the CIM;

[0122] The second operation includes:

[0123] The network service Neutron port is created through the CIM, and the Neutron port is added as a sub-interface to the main interface of the PF. The port information of the Neutron and the port information of the PF are sent to the VIM.

[0124] The VIM sends flow tables to the vSwitch on the DPU. The flow tables include network port information of the multiple first VFs, port information of the Neutron, and port information of the PF. The flow tables are used to implement the routing and forwarding of network packets corresponding to the containers.

[0125] Transceiver 510 is used to receive and send data under the control of processor 500.

[0126] Among them, Figure 5 In this context, the bus architecture may include any number of interconnected buses and bridges, specifically linking various circuits together, represented by one or more processors (processor 500) and memory (memory 520). The bus architecture may also link together various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 510 may be multiple elements, including transmitters and transceivers, providing a unit for communicating with various other devices over a transmission medium. The processor 500 is responsible for managing the bus architecture and general processing, and the memory 520 may store data used by the processor 500 during operation.

[0127] Optionally, the plurality of VFs are virtualized by the PF through I / O virtualization technology.

[0128] Optionally, the processor 500 is also used to read the program from the memory 520 and perform the following steps:

[0129] Configure the Media Access Control (MAC) address, Internet Protocol (IP) address, and Virtual Local Area Network (VLAN) information of the multiple Virtual Local Area Networks (VFs).

[0130] Optionally, the processor 500 is also used to read the program from the memory 520 and perform the following steps:

[0131] The PF is registered by the CIE to take over the port of the vSwitch.

[0132] Optionally, the processor 500 is also used to read the program from the memory 520 and perform the following steps:

[0133] When a new container needs to be created, the network port information of the VF in the flow table is updated, and the updated flow table is sent to the vSwitch through the VIM.

[0134] Optionally, packets communicating between the multiple VFs in the same VLAN are not input to the vSwitch, but are forwarded by the PF;

[0135] Cross-VLAN packets are input to the vSwitch and forwarded by the vSwitch according to the received flow table.

[0136] Optionally, the first operation and the second operation are executed in parallel.

[0137] The electronic device provided in this application embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0138] Furthermore, the computer-readable storage medium of this application embodiment is used to store a computer program, which can be executed by a processor. Figure 2 The steps in the method embodiment shown.

[0139] This application provides a computer program product, including computer instructions. When the computer instructions are executed by a processor, they implement the various processes of the container network configuration method embodiments described above and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0140] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0141] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can be physically included separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0142] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute some steps of the transmission and reception methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0143] The above description is the preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principles described in this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A container network architecture, characterized in that, The system includes a Container Cluster Manager (CCM), a Container Infrastructure Manager (CIM), a Virtualization Infrastructure Manager (VIM), a Data Processor (DPU), and a Host. The DPU deploys an on-chip System-on-a-Chip (SoC), a virtual switch (vSwitch), and a Physical Function (PF). The SoC has a Neutron network service. The Host deploys a Container Infrastructure Engine (CIE) and a Single Root I / O Virtualization (SR-IOV) driver module. The SR-IOV driver module has multiple Virtual Functions (VFs) corresponding to the PFs. The CIE has a Container Network Interface (CNI). The CCM communicates with the VIM, the VIM communicates with the CIM and the SoC, the CIM communicates with the CIE, the CIE communicates with the multiple VFs, the SoC communicates with the vSwitch, the vSwitch communicates with the PF, and the PF communicates with the SR-IOV driver module.

2. A container network configuration method, characterized in that, Applied to the container network architecture of claim 1, the method includes: Perform a first operation and a second operation, wherein the first operation includes: A container is created using the CIM, and the container is started on the CIE, with the container's environment parameters configured. The container network namespace is created through the CIE, and the SR-IOV driver module is called through the CNI in the CIE to configure the network ports of the multiple VFs and establish a mapping relationship between the first VF and the container, wherein the first VF is any one of the multiple VFs; The CIE sends the network port information of the first VF to the CIM; The second operation includes: The network service Neutron port is created through the CIM, and the Neutron port is added as a sub-interface to the main interface of the PF. The port information of the Neutron and the port information of the PF are sent to the VIM. The VIM sends flow tables to the vSwitch on the DPU. The flow tables include network port information of the multiple first VFs, port information of the Neutron, and port information of the PF. The flow tables are used to implement the routing and forwarding of network packets corresponding to the containers.

3. The method according to claim 2, characterized in that, The multiple VFs are virtualized by the PF through I / O virtualization technology.

4. The method according to claim 2, characterized in that, The configuration of the network ports of the multiple VFs includes: Configure the Media Access Control (MAC) address, Internet Protocol (IP) address, and Virtual Local Area Network (VLAN) information of the multiple Virtual Local Area Networks (VFs).

5. The method according to claim 2, characterized in that, The method further includes: The PF is registered by the CIE to take over the port of the vSwitch.

6. The method according to claim 2, characterized in that, The method further includes: When a new container needs to be created, the network port information of the VF in the flow table is updated, and the updated flow table is sent to the vSwitch through the VIM.

7. The method according to claim 2, characterized in that, Packets from the same VLAN are not input to the vSwitch, but are forwarded by the PF; Cross-VLAN packets are input to the vSwitch and forwarded by the vSwitch according to the received flow table.

8. The method according to claim 2, characterized in that, The first operation and the second operation are executed in parallel.

9. A container network configuration device, characterized in that, The container network configuration device, configured in the container network architecture of claim 1, comprises: An execution module is configured to perform a first operation and a second operation, wherein the first operation includes: A container is created using the CIM, and the container is started on the CIE, with the container's environment parameters configured. The container network namespace is created through the CIE, and the SR-IOV driver module is called through the CNI in the CIE to configure the network ports of the multiple VFs and establish a mapping relationship between the first VF and the container, wherein the first VF is any one of the multiple VFs; The CIE sends the network port information of the first VF to the CIM; The second operation includes: The network service Neutron port is created through the CIM, and the Neutron port is added as a sub-interface to the main interface of the PF. The port information of the Neutron and the port information of the PF are sent to the VIM. The VIM sends flow tables to the vSwitch on the DPU. The flow tables include network port information of the multiple first VFs, port information of the Neutron, and port information of the PF. The flow tables are used to implement the routing and forwarding of network packets corresponding to the containers.

10. An electronic device, comprising: A transceiver, a memory, a processor, and a computer program stored in the memory and executable on the processor; characterized in that the processor is configured to read the program in the memory to implement the steps in the container network configuration method as described in any one of claims 2 to 8.

11. A computer-readable storage medium for storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps in the container network configuration method as described in any one of claims 2 to 8.

12. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the steps in the container network configuration method as described in any one of claims 2 to 8.