A method, apparatus, device, medium and program product for allocating an elastic network card

Abstract

This application discloses a method, apparatus, device, medium, and program product for allocating elastic network interface cards (NICs), relating to the field of cloud service technology, and used to address core business requirements such as high-performance networks, large-scale clusters, and high-frequency creation and deletion of Pods. The method includes: in response to a cloud server's request to pre-create an elastic NIC, creating an elastic NIC for the cloud server; triggering the data processing unit corresponding to the cloud server to allocate multiple virtual function devices (VFMs) to the elastic NIC, connecting the elastic NIC to the cloud server; and in response to the creation of a target container on the cloud server, allocating a target VFM from the multiple VFMs to the target container, enabling the target container to communicate through the target VFM of the elastic NIC.

Description

Technical Field

[0001] This application relates to the field of cloud service technology, and in particular to a method, apparatus, device, medium and program product for allocating elastic network interface cards (NICs). Background Technology

[0002] Elastic Network Interfaces (ENIs) are virtual network interfaces that provide network interfaces and IP (Internet Protocol) addresses in a multi-tenant isolated Virtual Private Cloud (VPC). ENIs possess the basic network configuration and communication capabilities of traditional network interface cards (NICs). One or more ENIs can be attached to a cloud server, enabling the cloud server to have multi-NIC scalability. Multiple containers (Pods) can be created on a cloud server, and each container can communicate over the network via an ENI.

[0003] In traditional cloud container networking implementations based on elastic network interface cards (ENIs), two different implementation schemes are typically provided based on the user's actual network requirements: container networks where multiple Pods share an ENI and container networks where each Pod has its own ENI. Container networks where multiple Pods share an ENI can accommodate more Pods with fewer ENI resources and offer better management performance at the VPC management plane; however, network performance is relatively lower. Container networks where each Pod has its own ENI can achieve higher Pod network throughput, lower network latency, and better bandwidth isolation capabilities; however, they often cannot meet the requirements for high-density deployment on a single machine and rapid creation and deletion of Pods.

[0004] With the development of container architecture, upper-layer services are placing increasing demands on the network performance of the container's underlying data plane. How to meet the core requirements of services for high-performance networks, large-scale clusters, and high-frequency creation and deletion of Pods is a technical problem that urgently needs to be solved. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a method, apparatus, device, medium, and program product for allocating flexible network interface cards (NICs) to simultaneously meet core business requirements such as high-performance networks, large-scale clusters, and high-frequency creation and deletion of Pods.

[0006] To achieve the above objectives, the technical solution provided in this application is as follows:

[0007] In a first aspect, embodiments of this application provide a method for allocating flexible network interface cards (NICs), the method comprising:

[0008] In response to a request to pre-create an elastic network interface card (NIC) for a cloud server, create an elastic NIC for the cloud server.

[0009] The data processing unit corresponding to the cloud server is triggered to allocate multiple virtual function devices to the elastic network interface card (NIC) and connect the elastic NIC to the cloud server.

[0010] In response to the creation of a target container on the cloud server, a target virtual function device is allocated to the target container from the plurality of virtual function devices, so that the target container can communicate through the target virtual function device of the elastic network interface card.

[0011] In one possible implementation, creating an elastic network interface for the cloud server in response to a pre-created elastic network interface request from the cloud server includes:

[0012] In response to the cloud server's request to pre-create an elastic network interface, the system calls the VPC's create elastic network interface interface interface to create the resources for the elastic network interface.

[0013] In one possible implementation, the step of triggering the data processing unit corresponding to the cloud server to allocate multiple virtual function devices to the elastic network interface card (NIC) and connecting the elastic NIC to the cloud server includes:

[0014] The access elastic network interface of the private network is invoked, triggering the data processing unit corresponding to the cloud server to allocate multiple virtual function devices to the elastic network interface and initialize the queue resources of the virtual function devices;

[0015] Connect the elastic network card to the cloud server.

[0016] In one possible implementation, the method further includes:

[0017] The routing information of the elastic network interface card is broadcast to other cloud servers in the private network.

[0018] In one possible implementation, the step of allocating a target virtual function device (VVM) to the target container from the plurality of VVMs in response to the creation of the target container on the cloud server, so that the target container can communicate through the target VVM of the elastic network interface card (NIC), includes:

[0019] In response to the creation of a target container on the cloud server, the interface of the data processing unit is invoked to allocate an unoccupied target virtual function device to the target container from the plurality of virtual function devices;

[0020] Allocate an unused secondary network address of the elastic network interface card (NIC) to the target virtual function device, so that the target container can communicate through the queue resources of the target virtual function device of the elastic network interface card.

[0021] In one possible implementation, the method further includes:

[0022] Record the correspondence between the target container and the target virtual functional device.

[0023] In one possible implementation, the method further includes:

[0024] In response to the deletion of the target container, the correspondence between the target container and the target virtual functional device is deleted to release the target virtual functional device.

[0025] Secondly, embodiments of this application provide a flexible network interface card (NIC) allocation device, the device comprising:

[0026] A creation unit is used to create an elastic network interface for the cloud server in response to a request to pre-create an elastic network interface.

[0027] The first allocation unit is used to trigger the data processing unit corresponding to the cloud server to allocate multiple virtual function devices to the elastic network card and connect the elastic network card to the cloud server.

[0028] The second allocation unit is configured to allocate a target virtual function device (VVM) to the target container from among the plurality of VVMs in response to the creation of the target container on the cloud server, so that the target container can communicate through the target VVM of the elastic network interface card.

[0029] Thirdly, embodiments of this application provide an electronic device, the device comprising: a processor and a memory;

[0030] The memory is used to store instructions or computer programs;

[0031] The processor is configured to execute the instructions or computer program in the memory to cause the electronic device to perform the flexible network interface card allocation method described above.

[0032] Fourthly, embodiments of this application provide a computer-readable medium, characterized in that the computer-readable medium stores instructions or computer programs that, when executed on a device, cause the device to perform the flexible network interface card allocation method described above.

[0033] Fifthly, embodiments of this application provide a computer program product, characterized in that it includes a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the allocation method of the flexible network interface card as described in any of the preceding claims.

[0034] Compared with related technologies, the embodiments of this application have at least the following advantages:

[0035] This application embodiment pre-creates an Elastic Network Interface (ENI) on the cloud server, triggering the corresponding data processing unit of the cloud server to allocate multiple Virtual Functions (VF) devices to the ENI. When creating a target container on the cloud server, the corresponding data processing unit can be directly invoked to allocate one of the target VF devices from the pre-created ENI's VF devices for the target container. Pre-creating the Elastic Network Interface, with one ENI corresponding to multiple VF devices, allows for direct allocation of VF devices during target container creation, eliminating reliance on the VPC management plane. This reduces the overall frequency of VPC calls, improves the efficiency of Pod creation and deletion, and enables large-scale clustering. Simultaneously, each target container can exclusively utilize the hardware resources of a VF device, achieving higher network performance and container-level network bandwidth isolation. This application embodiment's single ENI multi-VF device solution better meets the requirements of cloud-native scenarios for high performance of the container network data plane, large-scale clustering, and low latency of the management plane. Attached Figure Description

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

[0037] Figure 1 This is a schematic diagram of two different container networking implementation schemes.

[0038] Figure 2 A schematic diagram illustrating an exemplary application scenario provided in this application embodiment;

[0039] Figure 3 A flowchart illustrating a method for allocating a flexible network interface card (NIC) according to an embodiment of this application;

[0040] Figure 4 This is a timing diagram of the allocation method for the flexible network interface card (NIC) in an embodiment of this application;

[0041] Figure 5 A schematic diagram of a flexible network interface card (NIC) allocation device provided in an embodiment of this application;

[0042] Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0043] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0044] To facilitate understanding and explanation of the technical solutions provided in the embodiments of this application, the background technology of the embodiments of this application will be described first below.

[0045] Elastic Network Interface (ENI) is a virtual network interface that provides network interface and IP address in a multi-tenant isolated Virtual Private Cloud (VPC). It typically has the following characteristics: it possesses the basic network configuration capabilities and network communication functions of a traditional network interface card (NIC); each ENI is hosted on a single SR-IOV (Single Root I / O Virtualization) VF (Virtual Function) within a Data Processing Unit (DPU); due to hardware specifications and host resource limitations, ENI cannot handle high concurrency or large-scale elastic creation and deletion; it allows one or more ENIs to be attached to a cloud server simultaneously, enabling the cloud server to have multi-NIC expansion capabilities, where the cloud server can be an Elastic Compute Service (ECS) or a Bare Metal server, etc.

[0046] Elastic network interface cards (NICs) can typically have multiple IP resources, including: a primary IP within a VPC, one or more secondary IPs within a VPC, one or more secondary CIDRs (Classless Inter-Domain Routing) within a VPC, and can simultaneously support IPv4 (Internet Protocol version 4) and IPv6 (Internet Protocol version 6) protocol stacks when necessary.

[0047] Elastic network interface cards (NICs), as a type of NIC virtualization technology that allows for dynamic hot-swapping, can be unbound and bound between different instances. They are widely used in various types of services in public cloud scenarios, such as cloud hosts ECS based on ENI networks, various cloud gateways, LB (Load Balance) clusters, NFV (Network Functions Virtualization) network elements, and cloud-native container networks based on ENI.

[0048] Container Network Interface (CNI) includes a set of specifications and libraries for writing plugins to configure network interfaces in Linux containers, as well as a range of supported plugins. Container networking is often implemented using cloud-native VPC and ENI technologies.

[0049] In traditional cloud-based container networking implementations based on ENI, two different container networking implementation schemes are typically provided based on the user's actual network requirements:

[0050] (1) The container network based on ENI multi-IP multi-Pod shared ENI has the following characteristics: each ENI is accompanied by multiple auxiliary IP addresses in the VPC; the auxiliary IPs on the ENI can be flexibly and dynamically applied for or released from the VPC management according to business needs, and the management API (Application Programming Interface) has good performance; when each Pod is created, an IP can be randomly assigned from multiple available auxiliary IPs of the ENI on the local cloud server as the Pod's primary IP, and the Pod's IP address is independent and unique within the VPC; all sub-network cards share the underlying SR-IOV VF hardware resources of their respective ENI.

[0051] (2) Container networks based on Pod exclusive ENI have the following characteristics: Since each Pod exclusively owns the ENI, each ENI generally only needs one main IP address; each Pod exclusively owns the entire ENI resource, and the main IP of the ENI is used as the IP of the container; the Pod exclusively owns the resources on the SR-IOV VF of the ENI, saving virtualization overhead.

[0052] See Figure 1The diagram illustrates two different container networking implementation schemes. Multiple container Pods can be created on a cloud server, with each cloud server corresponding to a DPU card. Here, eth1, ethX, and ethY serve as Elastic Network Interfaces (ENIs). eth1 connects to two Pods, representing a scenario where multiple Pods share an ENI; ethX and ethY each connect to one Pod, representing a scenario where each Pod has its own dedicated ENI. Each ENI corresponds to a Virtual Container Registry (VF) device, forming one hardware implementation scheme for the ENI. VPort, as a virtual port, manages the VF device. The Cloud vSwitch forwarding component provides VPC management services for creating ENIs and VFs.

[0053] Both container networking implementations have their own advantages and disadvantages. Generally, depending on the use case, the appropriate container networking solution can be selected based on the cluster size, data plane performance requirements, and management performance.

[0054] Container networks that allow multiple pods to share an ENI can achieve a larger number of pods and higher pod density per machine with fewer ENI resources. This results in lower performance requirements for the VPC management plane, better management performance, reduced latency for pod creation and deletion, and lower QPS (Queries Per Second) requirements for the VPC network. It is typically suitable for larger clusters or scenarios with higher pod density per machine. However, since multiple container pods share a single ENI hardware resource and VPC routing information, it is impossible to simultaneously guarantee high network performance and low latency.

[0055] Container networking based on dedicated ENIs for Pods can fully leverage the characteristics of dedicated ENIs to achieve higher Pod network throughput, lower network latency, and better bandwidth isolation capabilities, offering unique advantages, especially in scenarios with high network performance requirements. However, requesting and binding ENIs at the VPC level is a relatively time-consuming and slow process, consuming significant hardware resources and configuration deployment time overhead, and is more dependent on ENI hardware resources. It generally cannot meet the requirements of high-density deployment on a single machine and rapid creation and deletion of Pods at the granular level. It is typically suitable for scenarios with small cluster sizes but high network performance requirements.

[0056] As container architecture evolves, upper-layer applications place increasingly higher demands on the network performance of the container's underlying data plane. Simultaneously, there are higher requirements for metrics such as cluster deployment scale, Pod deployment density per machine, Pod creation / deletion frequency, and creation / deletion latency. With these increasing demands, businesses in public cloud environments will be able to achieve larger deployment scales, faster elasticity, lower service delivery costs, and better product returns.

[0057] Based on this, this application provides a method, apparatus, device, medium, and program product for allocating elastic network interface cards (NICs). In container networks, based on cloud-native ENI technology, it considers combining the advantages of exclusive ENI and shared ENI technologies. While making full use of existing hardware resource specifications, it simultaneously addresses the core business requirements for high-performance networks, large-scale clusters, and high-frequency creation and deletion of Pods, thus better meeting the needs of next-generation cloud-native container networks.

[0058] To facilitate understanding of the flexible network interface card (NIC) allocation method provided in the embodiments of this application, the following is combined with... Figure 2 The example scenario is shown below. See also... Figure 2 As shown in the figure, this figure is a schematic diagram of an exemplary application scenario provided in the embodiments of this application.

[0059] This application embodiment can be applied to cloud servers, which may include ECS (Elastic Compute Service) or Bare Metal servers, etc. Each cloud server corresponds to a DPU card, which is a hardware chip with network interface card (NIC) functionality. The cloud server can call the local Container Networking (CNI) service to access the Virtual Private Cloud (VPC) interface, thereby creating an Elastic Network Interface (ENI). Multiple Virtual Function (VF) devices (e.g., M VF devices) are pre-allocated to this ENI in the DPU, and each VF device has resources such as queues. This application embodiment proposes a novel cloud-native network interface card design with a single ENI and multiple VF hardware NICs, extending the relationship between ENI and VF hardware from 1:1 to 1:M. When a Pod needs to be created, the VF devices already created in the DPU are directly allocated to the Pod for use.

[0060] For example, as shown in the figure, multiple VF devices are allocated to ENI1 in the DPU card. Different containers on the cloud server, such as Pod1, Pod2, ..., PodX, connect to one VF device of ENI1 through interfaces eth1, eth1, ..., ethX, respectively, ensuring that each Pod can use an independent VF device. Similarly, multiple VF devices can be allocated to ENI0 in the DPU card. The current illustration shows Pod0 connecting to one VF device of ENI0 through interface eth0. It is understandable that if other Pods are created on the cloud server, other VF devices of ENI0 can also be allocated to them, as not shown in the figure. Thus, by introducing an aggregated multi-SR-IOV VF solution, the requirements of high performance in the network data plane and low latency in the network management plane are simultaneously met in cloud-native container network scenarios.

[0061] Those skilled in the art will understand that Figure 2The schematic diagram shown is merely one example in which embodiments of this application can be implemented. The scope of application of the embodiments of this application is not limited by any aspect of this framework.

[0062] To facilitate understanding of the embodiments of this application, the following description, in conjunction with the accompanying drawings, illustrates a method for allocating a flexible network interface card (NIC) according to the embodiments of this application.

[0063] See Figure 3 As shown, this figure is a flowchart of a method for allocating a flexible network interface card (NIC) according to an embodiment of this application. Figure 3 As shown, the method may include S301-S303:

[0064] S301: In response to the cloud server's request to pre-create an elastic network interface card (NIC), create an elastic NIC for the cloud server.

[0065] In this embodiment, the configuration and use of the container network can be divided into two parts: the ENI warm-up phase and the Pod creation phase. During the ENI warm-up phase, in response to the cloud server's request to pre-create an elastic network interface (ENI), the ENI can be created in advance. In practical applications, the cloud server can trigger the pre-creation request based on actual usage. When no Pods have been created on the cloud server, a pre-creation request can be triggered to request an ENI for the cloud server. When ENI resources are insufficient, for example, as described in the following embodiments, when all Virtual Functions (VF) devices allocated to the ENI are used by Pods, the cloud server can also trigger the pre-creation request to request another ENI for the cloud server. That is, one or more ENIs can be pre-created for the cloud server. Pre-creating an ENI for the cloud server can be understood as pre-creating ENI resources that a Pod can use before creating it on the cloud server. Furthermore, in this embodiment, the concepts of container and Pod are equivalent and are not distinguished.

[0066] Cloud servers typically include a service that provides Container Networking Interface (CNI), through which VPC interfaces can be called to create ENIs. S301 responds to the cloud server's request to pre-create an Elastic Network Interface (ENI). The specific implementation of creating an ENI for the cloud server can be found in the description of the following embodiments, and will not be repeated here.

[0067] S302: Triggers the data processing unit corresponding to the cloud server to allocate multiple virtual function devices to the elastic network interface card (NIC) and connect the elastic NIC to the cloud server.

[0068] A cloud server corresponds to a DPU card, which is a hardware chip with network interface card (NIC) functionality. A DPU can be partitioned into multiple Virtual Components (VFs) using SR-IOV technology. SR-IOV is a specification, a hardware-supported virtualization technology, that allows a single physical NIC to be divided into multiple virtual NICs. Each virtual NIC has its own MAC (Media Access Control) address, queue, and resource allocation, and can operate independently and communicate with the external environment. Through SR-IOV technology, physical hardware resources (such as bandwidth, queues, and cache) can be divided into multiple VFs. These VFs are isolated from each other and can be independently configured, managed, and controlled for network traffic.

[0069] During the ENI warm-up phase, after the ENI is created, the corresponding DPU on the cloud server can be further triggered to allocate multiple VF devices to the ENI. This embodiment of the application does not limit the number of VF devices allocated to each ENI; it can be set according to actual conditions, for example, allocating 16 VF devices to each ENI. In practical applications, the cloud server can also record the correspondence between ENIs and VF devices; for example, it can record that ENI1 is allocated VF0-VF15.

[0070] Then, the ENI needs to be attached to the cloud server to obtain its relevant information and bind it to the cloud server so that the ENI can be actually used. Similarly, the VPC interface can be called through CNI to access the ENI and allocate multiple VF devices. S302 triggers the data processing unit corresponding to the cloud server to allocate multiple virtual function devices for the elastic network interface card. The specific implementation method of connecting the elastic network interface card to the cloud server can be found in the description of the following embodiments, and will not be repeated here.

[0071] S303: In response to the creation of the target container on the cloud server, a target virtual function device is allocated to the target container from multiple virtual function devices so that the target container can communicate through the target virtual function device of the elastic network interface card.

[0072] During Pod creation, in response to the creation of the target container on the cloud server, a target VF device is directly selected from the VF devices pre-allocated for ENI and assigned to the target container. After the target container is created, it can use the resources of that target VF device within the ENI to achieve communication within the cloud network. Pod creation only involves actually creating the pre-allocated VF resources for the target container in the corresponding DPU, directly avoiding reliance on VPC management, resulting in high performance at the network management plane. Simultaneously, each VF is exclusive to the Pod, providing the Pod with high network data plane performance.

[0073] In one possible implementation, the method provided in this application embodiment may further include: recording the correspondence between the target container and the target virtual functional device.

[0074] After assigning a target VF device to a target container, the mapping between target containers and target VF devices can be recorded. Based on this record, when the number of VF devices corresponding to a given ENI reaches a threshold—for example, if all VF devices corresponding to a given ENI are in use, indicating insufficient resources for the ENI—a request to pre-create an elastic network interface card (ENI) can be triggered on the cloud server to re-apply for the ENI. This record allows for effective management of the usage of multiple VF devices for an ENI.

[0075] This application embodiment pre-creates an Elastic Network Interface (ENI) on the cloud server, triggering the corresponding data processing unit of the cloud server to allocate multiple Virtual Functions (VF) devices to the ENI. When creating a target container on the cloud server, the corresponding data processing unit can be directly invoked to allocate one of the target VF devices from the pre-created ENI's VF devices for the target container. Pre-creating the Elastic Network Interface, with one ENI corresponding to multiple VF devices, allows for direct allocation of VF devices during target container creation, eliminating reliance on the VPC management plane. This reduces the overall frequency of VPC calls, improves the efficiency of Pod creation and deletion, and enables large-scale clustering. Simultaneously, each target container can exclusively utilize the hardware resources of a VF device, achieving higher network performance and container-level network bandwidth isolation. This application embodiment's single ENI multi-VF device solution better meets the requirements of cloud-native scenarios for high performance of the container network data plane, large-scale clustering, and low latency of the management plane.

[0076] The following section continues to explain the specific implementation methods of S301-S303.

[0077] In one possible implementation, the specific implementation of S301 creating an elastic network interface card for the cloud server in response to the cloud server's request to pre-create an elastic network interface card may include:

[0078] In response to the cloud server's request to pre-create an elastic network interface, the system calls the VPC's create elastic network interface interface interface to create the resources for the elastic network interface.

[0079] In response to the cloud server's request to pre-create an Elastic Network Interface (ENI), the VPC interface can be called twice via CNI. First, the VPC's Create ENI interface needs to be called to create a logical resource for the ENI. This step also assigns a unique IP address within the VPC to the created ENI. At the VPC level, an ENI object is still used to manage the resources of an Elastic Network Interface, including subnets, routes, security groups, MAC addresses, IP addresses, secondary CIDRs, etc., and the user experience remains unchanged.

[0080] In one possible implementation, S302 triggers the data processing unit corresponding to the cloud server to allocate multiple virtual function devices to the elastic network interface card (NIC). The specific implementation of connecting the elastic NIC to the cloud server may include:

[0081] The system calls the access interface of the private network elastic network interface card (NIC), triggering the corresponding data processing unit of the cloud server to allocate multiple virtual function devices to the elastic NIC and initialize the queue resources of the virtual function devices; and connects the elastic NIC to the cloud server.

[0082] Next, the VPC's Elastic Network Interface (Attach ENI) interface needs to be called to truly bind the ENI created in the previous step to the corresponding cloud server. At the same time, by calling the Attach ENI interface, multiple SR-IOV VFs are pre-allocated for the ENI on the DPU at the backend of the cloud server, and the queue resources of each VF are initialized.

[0083] In practical applications, a multi-VF aggregation ENI can include 1 primary IP, N secondary CIDRs, M SR-IOVVFs, and K data transceiver queues for each VF, thus including a total of M*K data transceiver queues and corresponding overlay routing information. Here, N, M, and K are positive integers greater than 1.

[0084] The single ENI with multiple VF configuration in this application can reduce the overall frequency of VPC API calls through pre-allocation.

[0085] In one possible implementation, the method provided in this application embodiment may further include:

[0086] Broadcast the routing information of the elastic network interface card to other cloud servers in the private network.

[0087] Within a VPC cluster, which includes multiple cloud servers, the overlay routing information of the ENI also needs to be broadcast to other cloud servers within the VPC to complete the VPC network connectivity.

[0088] In one possible implementation, S303, in response to the creation of the target container on the cloud server, allocates a target virtual function device (VVM) to the target container from multiple VVMs, enabling the target container to communicate through the target VVM of the elastic network interface card (NIC). Specific implementations for this may include:

[0089] A1: In response to the creation of the target container on the cloud server, the interface of the data processing unit is called to allocate an unoccupied target virtual function device to the target container from multiple virtual function devices.

[0090] A2: Assign an unused secondary network address to the target virtual function device using the elastic network interface card (NIC) so that the target container can communicate through the queue resources of the target virtual function device using the elastic network interface card.

[0091] During the Pod creation phase, the container network creates ENI entity resources and configures IP addresses for the Pod based on the pre-warmed ENI. Since an ENI is associated with multiple VF device resources at the underlying level, this gives the container network better resource utilization flexibility when creating Pods using this ENI.

[0092] Container Networking (CNI) management can directly call the interface on the corresponding local DPU to randomly allocate an available VF device from multiple pre-warmed VF devices to the newly created Pod. This allows the newly created Pod to exclusively enjoy the queue resources on a single SR-IOV VF. At the same time, it can utilize the QoS (Quality of Service) rate limiting capability on the VF to achieve Pod-level network bandwidth isolation.

[0093] In a multi-VF configuration, the multi-IP capability of ENI can be leveraged, with N secondary CIDRs allocated on the ENI. Container network management can directly allocate a free, available IP address from the ENI's secondary CIDR pool on the local cloud server and configure IP routing and other settings on the previously allocated SR-IOV VF device. This combines the flexibility and low overhead of a multi-Pod shared ENI container network configuration.

[0094] During the Pod creation process described above, the entire configuration process is conducted locally in a closed loop, without any centralized management dependencies or VPC management overhead, including calls to the Create ENI and Attach ENI interfaces. This directly avoids the Pod creation and deletion processes' dependence on VPC management. The only interface calls involved are the actual creation of the pre-allocated VF device resources and the configuration of IP addresses by the local DPU. Therefore, the performance from a network management perspective is very high.

[0095] Meanwhile, since each VF is exclusive to a Pod, Pods do not need to share the queue resources of the SR-IOV VF. This brings higher network data plane performance to the Pod and allows for Pod-level bandwidth isolation by leveraging the QoS rate limiting capabilities on the VF. Therefore, the single ENI multi-VF solution in this application combines the advantages of high-performance network data plane in the Pod-exclusive ENI mode and low-latency management plane in the Pod-shared ENI mode. It can better meet the requirements of businesses in cloud-native scenarios for high performance of container network data plane and low latency of management plane.

[0096] In one possible implementation, the method provided in this application embodiment may further include:

[0097] In response to the deletion of the target container, the mapping between the target container and the target virtual functional device is deleted to release the target virtual functional device.

[0098] When a target container is deleted, there is no need to remove the hardware of the target VF device. Only the mapping between the target container and the target VF device needs to be deleted to release the target VF device, allowing it to be allocated to other Pods. This avoids the frequent hot-plugging of SR-IOV VF devices when Pods are frequently created and deleted, thus improving the efficiency of Pod creation and deletion.

[0099] See Figure 4 The figure shows a timing diagram of the allocation method of the elastic network interface card in an embodiment of this application.

[0100] During the ENI preheating phase, the cloud server triggers a request to pre-create an elastic network interface, calling the CNI service. This causes the CNI service to first call the VPC's Create ENI interface to create a logical resource for the ENI. After creating the ENI and allocating resources such as an IP address, the Create ENI interface can also return the ENI's identifier (id) to the CNI service. The CNI service then calls the VPC's Attach ENI interface, triggering the DPU to pre-allocate multiple VF devices for the ENI. After pre-allocating multiple VF devices, the DPU returns a success message to the Attach ENI interface. The Attach ENI interface also needs to trigger the DPU to bind drivers for each VF device, initializing the VF devices. After binding drivers for each VF device, the DPU returns the VF device's status information to the Attach ENI interface. The Attach ENI interface returns a successful ENI access message to the CNI service. Simultaneously, the Attach ENI interface can also broadcast the ENI's overlay routing information to other cloud servers within the VPC. Thus, the CNI service reports a successful preheating to the cloud server.

[0101] During the Pod creation phase, when the Pod is created on the cloud server, the DPU is invoked to allocate a target VF device for the Pod from multiple VF devices, thus completing the Pod creation.

[0102] In the cloud-native network interface card (NIC) configuration with a single ENI and multiple VFs, the embodiments of this application combine the advantages of both dedicated ENI NICs and shared ENI NICs. This enables container networks to achieve high hardware performance in the dedicated ENI configuration and low control plane dependency in the shared ENI configuration, providing a more stable and efficient cloud-native container network configuration.

[0103] Based on the flexible network interface card (NIC) allocation method provided in the embodiments of this application, the embodiments of this application also provide a flexible NIC allocation device, which is described below in conjunction with... Figure 5 Explanation and clarification will be provided. Among them, Figure 5 This is a schematic diagram of a flexible network interface card (NIC) allocation device provided in an embodiment of this application. It should be noted that for technical details of the flexible NIC allocation device provided in this embodiment, please refer to the relevant content of the flexible NIC allocation method above.

[0104] like Figure 5 As shown, the allocation device for the flexible network interface card (NIC) provided in this application embodiment may include:

[0105] Creation unit 501 is used to create an elastic network interface for the cloud server in response to the cloud server's request to pre-create an elastic network interface.

[0106] The first allocation unit 502 is used to trigger the data processing unit corresponding to the cloud server to allocate multiple virtual function devices to the elastic network card and connect the elastic network card to the cloud server.

[0107] The second allocation unit 503 is configured to allocate a target virtual function device (VVM) to the target container from among the plurality of VVMs in response to the creation of the target container on the cloud server, so that the target container can communicate through the target VVM of the elastic network interface card.

[0108] In one possible implementation, the creation unit is specifically used for:

[0109] In response to the cloud server's request to pre-create an elastic network interface, the system calls the VPC's create elastic network interface interface interface to create the resources for the elastic network interface.

[0110] In one possible implementation, the first allocation unit is specifically used for:

[0111] The access elastic network interface of the private network is invoked, triggering the data processing unit corresponding to the cloud server to allocate multiple virtual function devices to the elastic network interface and initialize the queue resources of the virtual function devices;

[0112] Connect the elastic network card to the cloud server.

[0113] In one possible implementation, the first allocation unit is further configured to:

[0114] The routing information of the elastic network interface card is broadcast to other cloud servers in the private network.

[0115] In one possible implementation, the second creation unit is specifically used for:

[0116] In response to the creation of a target container on the cloud server, the interface of the data processing unit is invoked to allocate an unoccupied target virtual function device to the target container from the plurality of virtual function devices;

[0117] Allocate an unused secondary network address of the elastic network interface card (NIC) to the target virtual function device, so that the target container can communicate through the queue resources of the target virtual function device of the elastic network interface card.

[0118] In one possible implementation, the device further includes:

[0119] A recording unit is used to record the correspondence between the target container and the target virtual functional device.

[0120] In one possible implementation, the device further includes:

[0121] The deletion unit is configured to delete the correspondence between the target container and the target virtual functional device in response to the deletion of the target container, so as to release the target virtual functional device.

[0122] Based on the aforementioned elastic network interface card (ENI) allocation device, this embodiment of the application pre-creates an ENI on the cloud server, triggering the corresponding data processing unit of the cloud server to allocate multiple Virtual Function (VF) devices to the ENI. When the cloud server creates a target container, it can directly call the corresponding data processing unit to allocate one of the target VF devices from the pre-created ENI's VF devices to the target container. By pre-creating the elastic network interface card, and with one ENI corresponding to multiple VF devices, VF devices can be directly allocated during target container creation, eliminating reliance on the VPC management plane. This reduces the overall frequency of VPC calls, improves the efficiency of Pod creation and deletion, and enables large-scale clustering. Simultaneously, each target container can exclusively occupy the hardware resources of a VF device, achieving higher network performance and container-level network bandwidth isolation. This embodiment of the application's single ENI multi-VF device solution better meets the requirements of businesses in cloud-native scenarios for high performance of the container network data plane, large-scale clustering, and low latency of the management plane.

[0123] In addition, this application embodiment also provides an electronic device, the device including a processor and a memory: the memory is used to store instructions or computer programs; the processor is used to execute the instructions or computer programs in the memory, so that the electronic device performs any implementation of the flexible network interface card allocation method provided in this application embodiment.

[0124] See Figure 6 The diagram illustrates a structural schematic of an electronic device 1300 suitable for implementing embodiments of the present disclosure. Terminal devices in embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0125] like Figure 6 As shown, electronic device 1300 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 1301, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1302 or a program loaded from storage device 1308 into random access memory (RAM) 1303. RAM 1303 also stores various programs and data required for the operation of electronic device 1300. Processing device 1301, ROM 1302, and RAM 1303 are interconnected via bus 1304. Input / output (I / O) interface 1305 is also connected to bus 1304.

[0126] Typically, the following devices can be connected to I / O interface 1305: input devices 1306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1309. Communication device 1309 allows electronic device 1300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 An electronic device 1300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0127] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 1309, or installed from storage device 1308, or installed from ROM 1302. When the computer program is executed by processing device 1301, it performs the functions defined in the methods of embodiments of this disclosure.

[0128] The electronic device provided in this embodiment belongs to the same inventive concept as the method provided in the above embodiments. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.

[0129] This application also provides a computer-readable medium storing instructions or computer programs that, when executed on a device, cause the device to perform any implementation of the flexible network interface card (NIC) allocation method provided in this application.

[0130] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0131] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and end-to-end networks (e.g., ad hoc end-to-end networks), as well as any currently known or future-developed networks.

[0132] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0133] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, enable the electronic device to perform the aforementioned methods.

[0134] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0135] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0136] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units / modules do not necessarily limit the specific unit itself.

[0137] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0138] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0139] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems or apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and relevant parts can be referred to the method section.

[0140] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0141] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0142] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0143] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for allocating flexible network interface cards (NICs), characterized in that, The method includes: In response to a request to pre-create an elastic network interface card (NIC) for a cloud server, create an elastic NIC for the cloud server. The data processing unit corresponding to the cloud server is triggered to allocate multiple virtual function devices to the elastic network interface card (NIC) and connect the elastic NIC to the cloud server. In response to the creation of a target container on the cloud server, a target virtual function device is allocated to the target container from the plurality of virtual function devices, so that the target container can communicate through the target virtual function device of the elastic network interface card.

2. The method according to claim 1, characterized in that, The step of creating an elastic network interface for the cloud server in response to the cloud server's request to pre-create an elastic network interface includes: In response to the cloud server's request to pre-create an elastic network interface, the system calls the VPC's create elastic network interface interface interface to create the resources for the elastic network interface.

3. The method according to claim 1, characterized in that, The step of triggering the data processing unit corresponding to the cloud server to allocate multiple virtual function devices to the elastic network interface card (NIC) and connecting the elastic NIC to the cloud server includes: The access elastic network interface of the private network is invoked, triggering the data processing unit corresponding to the cloud server to allocate multiple virtual function devices to the elastic network interface and initialize the queue resources of the virtual function devices; Connect the elastic network card to the cloud server.

4. The method according to claim 3, characterized in that, The method further includes: The routing information of the elastic network interface card is broadcast to other cloud servers in the private network.

5. The method according to claim 1, characterized in that, In response to creating a target container on the cloud server, allocating a target virtual function device (VVM) to the target container from the plurality of VVMs, so that the target container can communicate through the target VVM of the elastic network interface card (NIC), includes: In response to the creation of a target container on the cloud server, the interface of the data processing unit is invoked to allocate an unoccupied target virtual function device to the target container from the plurality of virtual function devices; Allocate an unused secondary network address of the elastic network interface card (NIC) to the target virtual function device, so that the target container can communicate through the queue resources of the target virtual function device of the elastic network interface card.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: Record the correspondence between the target container and the target virtual functional device.

7. The method according to any one of claims 1-5, characterized in that, The method further includes: In response to the deletion of the target container, the correspondence between the target container and the target virtual functional device is deleted to release the target virtual functional device.

8. A flexible network interface card (NIC) allocation device, characterized in that, The device includes: A creation unit is used to create an elastic network interface for the cloud server in response to a request to pre-create an elastic network interface. The first allocation unit is used to trigger the data processing unit corresponding to the cloud server to allocate multiple virtual function devices to the elastic network card and connect the elastic network card to the cloud server. The second allocation unit is configured to allocate a target virtual function device (VVM) to the target container from among the plurality of VVMs in response to the creation of the target container on the cloud server, so that the target container can communicate through the target VVM of the elastic network interface card.

9. An electronic device, characterized in that, The device includes: a processor and a memory; The memory is used to store instructions or computer programs; The processor is configured to execute the instructions or computer program in the memory to cause the electronic device to perform the flexible network interface card allocation method according to any one of claims 1-7.

10. A computer-readable medium, characterized in that, The computer-readable medium stores instructions or computer programs that, when executed on the device, cause the device to perform the resilient network interface card allocation method according to any one of claims 1-7.

11. A computer program product, characterized in that, It includes a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the allocation method of the flexible network interface card as described in any one of claims 1-7.

Images