Deployment method, apparatus, equipment and storage media for DPU-based Kubernetes clusters
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- YUSUR TECH CO LTD
- Filing Date
- 2024-09-11
- Publication Date
- 2026-05-26
Smart Images
Figure CN119211023B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, device and storage medium for deploying a k8s cluster based on a DPU. Background Technology
[0002] Currently, DPU network interface cards typically use a cloud-native network traffic offloading method based on Open Virtual Network (OVN). In this method, when a user creates a container Pod or virtual machine (VM) instance, Kubernetes first invokes the single root virtualization device plugin (SRIOV-DP CNI) to select a suitable Virtual Function (VF) interface from the user-defined SRIOV resource pool. Then, the selected VF device ID is passed to the OVN Kubernetes software-defined network controller plugin (ovn-kubernetes CNI). The ovn-kubernetes CNI adds the VF device to the newly created Pod or VM instance. Simultaneously, two components deployed on the DPU SoC side—the OVN SoC module and the OVN controller—respond to instance scheduling events. The OVN SoC module adds the representative port (vfr) corresponding to the VF to the OVS bridge. The OVN controller retrieves the relevant flow tables from the Open Virtual Network Interface (OVN DB) and distributes them to the OVS instance. OVS forwards network traffic associated with the Pod or VM instance.
[0003] However, SRIOV-DP and ovn-kubernetes CNI only allocate one VF per Pod or VM. Limited by the available hardware queues and other hardware resources for each VF, when the cloud server's computing resources are powerful enough, the bandwidth and throughput required for applications running in a Pod to send and receive network data will be very high, especially in DPU scenarios. After enabling the DPU network traffic hardware offloading feature, the hardware forwarding efficiency on the DPU is greatly improved. At this time, the available hardware resources of the VFs in the host-side Pod / VM will become the performance bottleneck. If CNI could create and add a dynamic aggregation interface containing multiple VFs for each Pod or VM instance, it would multiply the hardware resources of the Pod or VM interface, thereby increasing the upper limit of bandwidth and throughput performance provided by a single instance for the application. Summary of the Invention
[0004] This application provides a Kubernetes cluster deployment method based on DPU to improve the network forwarding performance of container instances in cloud-native clusters.
[0005] In a first aspect, embodiments of this application provide a method for deploying a Kubernetes cluster based on a DPU, including:
[0006] Receive the container instance deployed by the user and determine two virtual function ports and their corresponding second identifiers;
[0007] Obtain the first identifier of the device corresponding to the two virtual function ports, and call the container network interface plugin. The container network interface plugin is used to create logically bound virtual function ports. The working mode of creating logically bound virtual function ports is dynamic link aggregation mode.
[0008] The two virtual function ports are added to the logically bound virtual function ports according to the first identifier; the logically bound virtual function ports are added to the kernel namespace of the container, the logically bound virtual function ports are the network interfaces of the container, and IP addresses are assigned to the network interfaces of the container through the software-defined networking controller plugin;
[0009] Send the first identifier and the second identifier, whereby the first identifier is used to create a logically bound virtual function representative port and the second identifier is used to create a logically bound uplink interface;
[0010] According to the second identifier, the two uplink interfaces corresponding to the two physical function interfaces are added as sub-interfaces to the logically bound uplink interface, and the working mode of the logically bound uplink interface is set to dynamic link aggregation mode.
[0011] Add the logically bound virtual function representative port and the logically bound uplink interface to the OVS bridge;
[0012] Obtain the flow table related to the container and the OVS configuration information of the logically bound virtual function representative port;
[0013] The container-related flow tables and the OVS configuration information are sent to the OVS instance.
[0014] In one possible implementation, the two virtual function ports belong to different physical function ports, and the two virtual function ports include a first virtual function port and a second virtual function port, with the first virtual function port and the second virtual function port corresponding to different resource pools.
[0015] In one possible implementation, the second identifier includes a third identifier and the fourth identifier, wherein the third identifier corresponds to the first virtual function port and the fourth identifier corresponds to the second virtual function port.
[0016] In one possible implementation, the container network interface plugin is used to create the logically bound virtual function port for the container instance based on the CRD resource definition when the container instance is scheduled by a worker node.
[0017] Secondly, embodiments of this application provide a Kubernetes cluster deployment device based on a DPU, comprising:
[0018] The receiving module is used to receive the container instance deployed by the user and determine the two virtual function ports and the corresponding second identifier;
[0019] The first acquisition module is used to acquire the first identifier of the device corresponding to the two virtual function ports, and call the container network interface plugin. The container network interface plugin is used to create logically bound virtual function ports. The working mode of creating logically bound virtual function ports is dynamic link aggregation mode.
[0020] The first adding module is used to add the two virtual function ports to the logically bound virtual function ports according to the first identifier; add the logically bound virtual function ports to the kernel namespace of the container, wherein the logically bound virtual function ports are the network interfaces of the container, and assign IP addresses to the network interfaces of the container through the software-defined networking controller plugin;
[0021] The first sending module is used to send the first identifier and the second identifier, wherein the first identifier is used to create a logically bound virtual function representative port, and the second identifier is used to create a logically bound uplink interface;
[0022] The second adding module is used to add two uplink interfaces corresponding to two physical function interfaces as sub-interfaces to the logically bound uplink interface according to the second identifier. The working mode of the logically bound uplink interface is set to dynamic link aggregation mode.
[0023] The third module adds the logically bound virtual function representative port and the logically bound uplink interface to the OVS bridge.
[0024] The second acquisition module is used to acquire the flow table related to the container and the OVS configuration information of the logically bound virtual function representative port;
[0025] The second sending module is used to send the container-related flow table and the OVS configuration information to the OVS instance.
[0026] In one possible implementation, the two virtual function ports belong to different physical function ports, and the two virtual function ports include a first virtual function port and a second virtual function port, with the first virtual function port and the second virtual function port corresponding to different resource pools.
[0027] In one possible implementation, the second identifier includes a third identifier and the fourth identifier, wherein the third identifier corresponds to the first virtual function port and the fourth identifier corresponds to the second virtual function port.
[0028] In one possible implementation, the container network interface plugin is used to create the logically bound virtual function port for the container instance based on the CRD resource definition when the container instance is scheduled by a worker node.
[0029] Thirdly, embodiments of this application also provide an electronic device, which includes:
[0030] At least one processor;
[0031] and memory that is communicatively connected to at least one processor;
[0032] The memory stores instructions that can be executed by at least one processor, which, when executed by at least one processor, cause the electronic device to perform a k8s cluster deployment method as described in any of the embodiments of the first aspect of this application.
[0033] Fourthly, embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement any of the k8s cluster deployment methods of the first aspect of embodiments of this application.
[0034] Fifthly, this disclosure also provides a computer program product comprising computer execution instructions, which, when executed by a processor, are used to implement the k8s cluster deployment method as described in any embodiment corresponding to the first aspect of this disclosure.
[0035] In summary, the method shown in this application embodiment addresses the bottleneck in network forwarding performance of Pod instances in cloud-native networks when a single virtualized SRIOV interface becomes a bottleneck due to resource limitations such as hardware queues. By aggregating multiple VF interfaces, Pod instances can achieve higher network forwarding performance. Attached Figure Description
[0036] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.
[0037] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0038] Figure 1 This is a schematic diagram of the Kubernetes cluster deployment structure of the DPU provided in the embodiments of this application;
[0039] Figure 2 A schematic diagram of the DPU-based Kubernetes cluster deployment method provided in this application embodiment;
[0040] Figure 3 A schematic diagram of a DPU-based Kubernetes cluster deployment device provided in this application embodiment;
[0041] Figure 4 The Kubernetes cluster deployment device based on DPU provided in this application embodiment. Detailed Implementation
[0042] In the following description, when referring to the accompanying drawings, the same numbers in different drawings denote the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.
[0043] The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.
[0044] It should be noted that, in this document, relational terms such as "first" and "second" are used merely 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.
[0045] The terminology involved in this invention will be described by way of example below.
[0046] Cloud native technologies enable organizations to build and run elastically scalable applications in new, dynamic environments such as public, private, and hybrid clouds. Key cloud native technologies include containers, service meshes, microservices, immutable infrastructure, and declarative APIs. These technologies enable the construction of loosely coupled systems that are fault-tolerant, easy to manage, and observable. Combined with reliable automation, cloud native technologies allow engineers to easily make frequent and predictable major changes to systems.
[0047] DPU: Data Processing Unit. As a dedicated hardware accelerator, it is a next-generation computing processor designed for data-centric computing. It integrates complete data center functionality onto a single chip, forming one of the three pillars of modern computing along with the CPU and GPU. By using specially designed hardware accelerators to rapidly process incoming data packets, processing latency can be reduced and throughput increased.
[0048] Kubernetes (K8S): Its full name is Kubernetes, and K8S is its abbreviation, using the number "8" to replace the eight characters of "ubernete". It is a container-based cluster management platform, also known as an open-source container orchestration platform, used to automate the deployment, scaling, and management of containerized applications. It provides a flexible and scalable way to manage containerized applications and offers a range of features to simplify application deployment, scheduling, self-healing, and scaling.
[0049] SOC: System On Chip, meaning it's a product, a dedicated integrated circuit that contains a complete system and all embedded software. A DPU SoC does not belong to the node resources of a Kubernetes cluster; it serves only as an independent operating system on the DPU network interface card for running software programs.
[0050] CNI / CNI stands for Container Network Interface, a network model used to implement multi-container communication. It's responsible for creating and managing network interfaces for containers, including assigning IP addresses, configuring routes, and setting network policies. CNI plugins can implement these functions based on different network implementations, such as Linux bridging, VLANs, and overlay networks.
[0051] Pod: Short for Point of Delivery, Kubernetes encapsulates one or more containers into a high-level structure called a pod. Any container within the same pod will share the same namespace and local network. Containers can easily communicate with other containers within the same container, as if they were on the same machine while maintaining a degree of isolation.
[0052] CRD is an abbreviation for CustomResourceDefinition, which is a custom resource definition used to manage the configuration of a pod's resources. For example, one pod corresponds to one CRD configuration.
[0053] PF / pf: This is an abbreviation for Physical Function, referring to the actual function of a physical network interface card (NIC). It can directly interact with the physical network. The PF is responsible for managing and controlling resources related to the VF, as well as handling communication between VFs.
[0054] OVN (Open Virtual Network) is an open-source virtualization network project that uses OVS as its underlying technology. It enables network interconnection between virtual machines and containers by providing a flexible and programmable data path between kernel space and user space. It offers rich network functionalities and easy-to-use management interfaces, allowing users to build and manage complex virtual network environments.
[0055] OVS: OpenvSwitch, a virtual forwarding software. OVS is a high-quality, multi-layered virtual switching software. Its purpose is to support large-scale network automation through programmable extensions, while also supporting standard management interfaces and protocols.
[0056] ovn-kubernetes is a Kubernetes CNI based on OVN (Open Virtual Network). It provides an efficient, reliable, and flexible network solution to meet the communication needs between containers in a Kubernetes cluster and between containers and external networks. In DPU scenarios, ovn-kubernetes CNI offloads the forwarding plane OVS to the DPU SoC. ovn-kubernetes guides the OVS forwarding plane on the DPU SoC to forward traffic by using OpenFlow flow tables to provide network and service information for the entire Kubernetes cluster.
[0057] SRIOV: Single Root Virtualization, which divides the network interface card (NIC) into a Virtual Function (VF) and a Physical Function (PF). SRIOV CNI refers to the interface on a worker node with SRIOV functionality.
[0058] Bond: Bond is a network technology primarily used to bind multiple physical network interface cards (NICs) to a single logical NIC. This achieves purposes such as link redundancy, bandwidth expansion, and load balancing. Bond technology is mainly used in production scenarios with high network throughput and demanding network stability, and is a commonly used technique to improve performance and reliability.
[0059] Figure 1 This is a schematic diagram of a Kubernetes cluster deployment structure for a DPU provided in an embodiment of this application. Figure 1 In this process, both hardware and software are deployed separately. On the hardware side, the DPU network interface card (NIC) is installed on the cloud server nodes in the data center, providing a high-bandwidth, low-latency heterogeneous network computing acceleration engine for the cloud server nodes.
[0060] In terms of software deployment, SRIOV CNI is deployed on the Kubernetes cluster control nodes and worker nodes to define and create PF and VF resource pools available for container pod instances on each worker node. Bond CNI, a network container interface, is deployed on each worker node of the Kubernetes cluster. When a container pod instance is scheduled to a worker node, Bond CNI defines a logically bound virtual function (bond VF) interface for that instance based on a user-defined resource definition (CRD). The available PF resource pools and the VF resource pools allocated to each PF are configured through the CRDs related to Bond CNI. The relevant components of ovn-kubernetes CNI are deployed on the Kubernetes cluster control nodes, worker nodes, and DPU SoC to provide basic network capabilities for the Kubernetes cluster.
[0061] Among them, the control node deploys the OVN Control Center component, which includes ovn-kubernetes control plane related components and OVN database related components.
[0062] The worker node deploys the ovn-kubernetes CNI component.
[0063] The OVN controller and OVN SoC module are deployed on the DPU SoC.
[0064] Deploy the MultusCNI collaboration component on the control node and worker node of the Kubernetes cluster to provide Kubernetes with the collaborative working capabilities of SRIOV CNI, Bond CNI, and ovn-kubernetes CNI.
[0065] exist Figure 1 In the code, number 1 means: select 2SRIOV VFs from two different PFs, that is, select one SRIOV VF device from each of the VF resource pools created by two different PFs, for a total of two SRIOV VF devices.
[0066] Number 2 indicates: Device IDs, i.e., device identifiers.
[0067] Number 3 indicates: Create bond port, that is, create a Bond port.
[0068] Number 4 means: set port to pod NS, which means adding the created Bond port to the Pod's namespace kernel namespace.
[0069] Number 5 means: get PF IDs and VF IDs, that is, retrieve PF IDs and VF IDs.
[0070] Number 6 means: Create bond vfr port and bond uplink port with LACP mode, and add the two bond ports on OVS bridge.
[0071] Number 7 indicates: Synchronize the openflow tables related to the bond VF port from OVN DB, that is, synchronize the openflow flow table information related to the bond VF interface from OVN DB.
[0072] Number 8 indicates: Download the OpenFlow tables related to the bond port, which means downloading the synchronized bond port flow table information to the OVS instance.
[0073] Number 9 indicates a "miss up call," meaning a missing entry event.
[0074] Number 10 indicates: Download hw_offloaded tables, which is the hardware offload table entry.
[0075] Figure 2 This is a schematic diagram illustrating a Kubernetes cluster deployment method based on DPU, provided as an embodiment of this application. Figure 2 The process includes steps S201 to S207. Each step is described in detail below.
[0076] Step S201: Receive the container instance deployed by the user and determine the two virtual function ports and the corresponding second identifier.
[0077] In one possible implementation, the two virtual function ports include a first virtual function port and a second virtual function port, wherein the resource pools corresponding to the first virtual function port and the second virtual function port are different.
[0078] Understandably, when Kubernetes receives a user-deployed container Pod instance, the kubelet calls the SRIOV CNI to select two physical function ports (PFs) from the available physical function port (PF) resource pool on the worker node. Then, from the SRIOVVF resource pool corresponding to each PF, one virtual function port (VF) is selected. The two virtual function ports (VFs) include a first virtual function port and a second virtual function port, and the resource pools corresponding to the first virtual function port and the second virtual function port are different.
[0079] In one possible implementation, the second identifier includes a third identifier and the fourth identifier, wherein the third identifier corresponds to the first virtual function port and the fourth identifier corresponds to the second virtual function port.
[0080] Understandably, here the first identifier refers to the identifiers of two devices, and each device's identifier corresponds to a different virtual function port.
[0081] In this embodiment, the second identifier includes identifiers for two Virtual Function Ports (VFs), wherein the identifiers for the two VFs include a third identifier and a fourth identifier. The third identifier corresponds to the first virtual function port, and the fourth identifier corresponds to the second virtual function port. Each VF and PF has a unique identifier. This identifier can be the unique PCI bus address corresponding to the virtual function port (VF) in the operating system, or it can be another address, but in practice, the PCI bus address is generally used.
[0082] Step S202: Obtain the first identifier of the device corresponding to the two virtual function ports, and call the container network interface plugin. The container network interface plugin is used to create logically bound virtual function ports. The working mode of creating logically bound virtual function ports is dynamic link aggregation mode.
[0083] In one possible implementation, the container network interface plugin is used to create the logically bound virtual function port for the container instance based on the CRD resource definition when the container instance is scheduled by a worker node.
[0084] Step S203: Add the two virtual function ports to the logically bound virtual function ports according to the first identifier; add the logically bound virtual function ports to the kernel namespace of the container, wherein the logically bound virtual function ports are the network interfaces of the container, and assign IP addresses to the network interfaces of the container through the software-defined networking controller plugin.
[0085] Understandably, Kubernetes obtains the first identifier (VF device ID) of the devices corresponding to the two assigned virtual function ports and calls the Container Network Interface Plugin (Bond CNI). Bond CNI creates a logically bound virtual function port (bond VF port), adds the two selected virtual function ports (VF) as sub-interfaces to the bond VF port based on the VF device ID, and sets the bond mode to LACP dynamic link aggregation mode.
[0086] Understandably, the kubelet calls the ovn-kubernetes CNI (OVN Kubernetes software-defined networking controller plugin) to add the created bond VF port to the Pod's kernel namespace, logically binding the virtual function port as the Pod's network interface NIC. The OVN Kubernetes software-defined networking controller plugin then assigns an IP address to the interface.
[0087] Step S204: Send the first identifier and the second identifier, whereby the first identifier is used to create a logically bound virtual function representative port and the second identifier is used to create a logically bound uplink interface.
[0088] Understandably, this step involves sending the first identifier and the second identifier to the on-chip system component deployed on the DPU. The first identifier is used to create a logically bound virtual function delegate port, and the second identifier is used to create a logically bound uplink interface. That is, the third and fourth identifiers included in the second identifier are both used to create the logically bound uplink interface.
[0089] Step S205: According to the second identifier, add the corresponding two virtual function representative ports as sub-interfaces to the logically bound virtual function representative port, and set the working mode of the logically bound virtual function representative port to dynamic link aggregation mode.
[0090] Step S206: Add the logically bound virtual function representative port and the logically bound uplink interface to the OVS bridge.
[0091] Understandably, after receiving the second identifier VF ID, the OVN SoC module (DPU) creates a bond interface, which includes a VFR port interface.
[0092] In one possible implementation, a logically bound virtual function representative port (bondvfr port) is created on the DPU SoC, and based on the obtained VF ID, the corresponding two VF representative ports (VFr) are added as sub-interfaces to the bond vfr port, and the bond port mode is set to LACP dynamic link aggregation mode.
[0093] Understandably, adding a bond interface to an OVS bridge means adding a logically bound virtual function representative port (bondvfr port) to the OVS bridge.
[0094] Step S207: Obtain the flow table related to the container and the OVS configuration information of the logically bound virtual function representative port.
[0095] Step S208: Send the container-related flow tables and the OVS configuration information to the OVS instance.
[0096] Understandably, the OVN Controller component deployed on the DPU SoC synchronously obtains the latest flow tables related to the newly created container Pod and the bond VF interface configuration from the OVN Control Center component. The OVN Controller component then distributes the OpenFlow flow table information related to the newly created Pod and the bond VF interface to the OVS instance.
[0097] When a data flow related to the created Pod instance arrives at the DPU network card, the ASIC hardware forwarding engine will fail to forward the packet due to the lack of flow-related information, triggering a missing entry upload event (miss up call). The first packet will be uploaded to the OVS instance on the DPU SoC. The OVS instance will then forward the packet based on the OpenFlow flow table information and related flow tables mentioned above.
[0098] After the first packet is forwarded, the OVS instance on the DPU SoC sends a hardware offload table entry related to the flow to the ASIC's hardware forwarding engine. Subsequent packets can be forwarded directly after the hardware table is found.
[0099] It is understood that the above-described embodiments are based on ASIC DPU network cards, but the present invention can also be applied to any network card that supports SRIOV features and network traffic hardware offloading capabilities, such as SmartNIC smart network cards. This application does not impose any limitations on these embodiments.
[0100] This embodiment uses Kubernetes as an example of a cloud-native orchestration tool. The present invention is also applicable to other cloud-native cluster orchestration tools, such as OpenShift. This application does not impose any limitations on these applications.
[0101] This embodiment uses a Pod as an example of Kubernetes scheduling. The present invention is also applicable to VMs and bare metal instances managed by Kubernetes. This application does not impose any limitations on these embodiments.
[0102] This embodiment uses ovn-kubernetes CNI as an example to provide a network interface for a Kubernetes cluster. This invention is also applicable to any open-source or self-developed CNI that serves as an SDN controller / forwarding plane, such as kube-ovn, Antrea, etc. This application does not impose any limitations on these embodiments.
[0103] In summary, the method shown in this application embodiment addresses the bottleneck in network forwarding performance of Pod instances in cloud-native networks when a single virtualized SRIOV interface becomes a bottleneck due to resource limitations such as hardware queues. By aggregating multiple VF interfaces, Pod instances can achieve higher network forwarding performance.
[0104] Figure 3 A schematic diagram of a DPU-based Kubernetes cluster deployment device provided in this application embodiment includes the following modules:
[0105] The receiving module 301 is used to receive the container instance deployed by the user and determine the two virtual function ports and the corresponding second identifier;
[0106] The first acquisition module 302 is used to acquire the first identifier of the device corresponding to the two virtual function ports, and call the container network interface plugin. The container network interface plugin is used to create logically bound virtual function ports. The working mode of creating logically bound virtual function ports is dynamic link aggregation mode.
[0107] The first adding module 303 is used to add the two virtual function ports to the logically bound virtual function ports according to the first identifier; add the logically bound virtual function ports to the kernel namespace of the container, wherein the logically bound virtual function ports are the network interfaces of the container, and assign IP addresses to the network interfaces of the container through the software-defined networking controller plugin;
[0108] The first sending module 304 is used to send the first identifier and the second identifier, wherein the first identifier is used to create a logically bound virtual function representative port, and the second identifier is used to create a logically bound uplink interface.
[0109] The second adding module 305 is used to add two uplink interfaces corresponding to two physical function interfaces as sub-interfaces to the logically bound uplink interface according to the second identifier, wherein the working mode of the logically bound uplink interface is set to dynamic link aggregation mode.
[0110] The third addition module 306 adds the logically bound virtual function representative port and the logically bound uplink interface to the OVS bridge;
[0111] The second acquisition module 307 is used to acquire the flow table related to the container and the OVS configuration information of the logically bound virtual function representative port;
[0112] The second sending module 308 is used to send the container-related flow table and the OVS configuration information to the OVS instance.
[0113] In one possible implementation, the two virtual function ports belong to different physical function ports, and the two virtual function ports include a first virtual function port and a second virtual function port, with the first virtual function port and the second virtual function port corresponding to different resource pools.
[0114] In one possible implementation, the second identifier includes a third identifier and the fourth identifier, wherein the third identifier corresponds to the first virtual function port and the fourth identifier corresponds to the second virtual function port.
[0115] In one possible implementation, the container network interface plugin is used to create the logically bound virtual function port for the container instance based on the CRD resource definition when the container instance is scheduled by a worker node.
[0116] It is understood that the apparatus provided in the embodiments of this application is used to implement Figure 2 All methods described in the embodiments.
[0117] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown below. Figure 4 As shown, the electronic device 400 includes a memory 410 and a processor 420.
[0118] The memory 410 stores a computer program that can be executed by at least one processor 420. This computer program is executed by at least one processor 420 to cause the electronic device to implement the methods provided in any of the above embodiments.
[0119] The memory 410 and the processor 420 can be connected via a bus 430.
[0120] The relevant explanations can be understood by referring to the corresponding descriptions and effects in the method embodiments, and will not be repeated here.
[0121] One embodiment of this application provides a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to perform the following: Figure 2 The method of any corresponding embodiment.
[0122] The computer-readable storage medium can be ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.
[0123] One embodiment of this application provides a computer program product comprising computer-executable instructions, which, when executed by a processor, are used to implement, as described above. Figure 2 The method of any corresponding embodiment.
[0124] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules 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 apparatuses or modules may be electrical, mechanical, or other forms.
[0125] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope of this application is indicated by the claims.
[0126] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.
Claims
1. A method for deploying a Kubernetes cluster based on a DPU, characterized in that, include: Receive the container instance deployed by the user and determine two virtual function ports and their corresponding second identifiers; Obtain the first identifier of the device corresponding to the two virtual function ports, and call the container network interface plugin. The container network interface plugin is used to create logically bound virtual function ports. The working mode of creating logically bound virtual function ports is dynamic link aggregation mode. The two virtual function ports are added to the logically bound virtual function ports according to the first identifier; the logically bound virtual function ports are added to the kernel namespace of the container, the logically bound virtual function ports are the network interfaces of the container, and IP addresses are assigned to the network interfaces of the container through the software-defined networking controller plugin; Send the first identifier and the second identifier, whereby the first identifier is used to create a logically bound virtual function representative port and the second identifier is used to create a logically bound uplink interface; According to the second identifier, the two uplink interfaces corresponding to the two physical function interfaces are added as sub-interfaces to the logically bound uplink interface, and the working mode of the logically bound uplink interface is set to dynamic link aggregation mode. Add the logically bound virtual function representative port and the logically bound uplink interface to the OVS bridge; Obtain the flow table related to the container and the OVS configuration information of the logically bound virtual function representative port; The container-related flow tables and the OVS configuration information are sent to the OVS instance.
2. The method according to claim 1, characterized in that, The two virtual function ports belong to different physical function ports. The two virtual function ports include a first virtual function port and a second virtual function port. The resource pools corresponding to the first virtual function port and the second virtual function port are different.
3. The method according to claim 2, characterized in that, The second identifier includes a third identifier and a fourth identifier, wherein the third identifier corresponds to the first virtual function port and the fourth identifier corresponds to the second virtual function port.
4. The method according to any one of claims 1-3, characterized in that, The container network interface plugin is used to create the logically bound virtual function port for the container instance based on the CRD resource definition when the container instance is scheduled by the worker node.
5. A Kubernetes cluster deployment device based on DPU, characterized in that, include: The receiving module is used to receive the container instance deployed by the user and determine the two virtual function ports and the corresponding second identifier; The first acquisition module is used to acquire the first identifier of the device corresponding to the two virtual function ports, and call the container network interface plugin. The container network interface plugin is used to create logically bound virtual function ports. The working mode of creating logically bound virtual function ports is dynamic link aggregation mode. The first adding module is used to add the two virtual function ports to the logically bound virtual function ports according to the first identifier; add the logically bound virtual function ports to the kernel namespace of the container, wherein the logically bound virtual function ports are the network interfaces of the container, and assign IP addresses to the network interfaces of the container through the software-defined networking controller plugin; The first sending module is used to send the first identifier and the second identifier, wherein the first identifier is used to create a logically bound virtual function representative port, and the second identifier is used to create a logically bound uplink interface; The second adding module is used to add two uplink interfaces corresponding to two physical function interfaces as sub-interfaces to the logically bound uplink interface according to the second identifier. The working mode of the logically bound uplink interface is set to dynamic link aggregation mode. The third module adds the logically bound virtual function representative port and the logically bound uplink interface to the OVS bridge. The second acquisition module is used to acquire the flow table related to the container and the OVS configuration information of the logically bound virtual function representative port; The second sending module is used to send the container-related flow table and the OVS configuration information to the OVS instance.
6. The apparatus according to claim 5, characterized in that, The two virtual function ports belong to different physical function ports. The two virtual function ports include a first virtual function port and a second virtual function port. The resource pools corresponding to the first virtual function port and the second virtual function port are different.
7. The apparatus according to claim 6, characterized in that, The second identifier includes a third identifier and a fourth identifier, wherein the third identifier corresponds to the first virtual function port and the fourth identifier corresponds to the second virtual function port.
8. The apparatus according to any one of claims 5-7, characterized in that, The container network interface plugin is used to create the logically bound virtual function port for the container instance based on the CRD resource definition when the container instance is scheduled by the worker node.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 4.
10. A computer program product comprising computer-executable instructions, characterized in that, The computer executes instructions when they are executed by the processor to implement the method as described in any one of claims 1 to 4.