Dpu-based k8s cluster deployment method and device, equipment and storage medium

Abstract

The application provides a DPU-based k8s cluster deployment method and device, equipment and storage medium, including: k8s receives the container instance deployed by the user, and determines two virtual function ports; obtain the identifier of the corresponding equipment, and call the network container interface; according to the identifier, add the virtual function port to the logical binding virtual function port and add it to the kernel namespace of the container; through the controller plug-in of the software-defined network, allocate IP address and MAC address for the container network interface; add the corresponding two virtual function representative ports as sub-interfaces to the logical binding virtual function representative port, and set the working mode to master-slave mode; create a logical binding uplink interface, and add the uplink interface, and set the working mode to master-slave mode; and add the representative port and the uplink interface to the OVS bridge; and downlink the container-related flow table and configuration information to the OVS instance, so as to improve the reliability of the network communication of the container instance in the cloud native cluster.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of data processing, and particularly relate to a k8s cluster deployment method and device based on DPU, equipment and storage medium. BACKGROUND

[0002] Currently, a cloud-native network traffic offload method based on Open Virtual Network (OVN) is usually used on the DPU network card. In this method, after the user creates a container Pod or a virtual machine VM instance, Kubernetes first calls a single-root virtualization device plugin (SRIOV device plugin, SRIOV-DP CNI) to select a virtual function VF interface that meets the requirements from a user-defined SRIOV resource pool, and then passes the selected VF device ID to an OVN K8s software-defined network controller plugin (ovn-kubernetes CNI). The ovn-kubernetes CNI adds the VF device to the newly created Pod or virtual machine instance. At the same time, two components deployed on the DPU SoC side, an OVN Soc module and an OVN Controller, respond to the instance scheduling event. The OVN Soc module adds a vfr representing port corresponding to the VF to the ovs bridge. The OVN Controller obtains the related flow table from the Open Virtual Network Database (OVN DB) and issues it to the OVS instance. The OVS forwards the network traffic related to the Pod or VM instance.

[0003] However, in the current solution, SRIOV-DP and ovn-kubernetes CNI only allocate one VF for each Pod or VM. When the VF interface or the PF interface to which the VF interface belongs has a software or hardware problem, causing the VF interface to fail, the Pod or VM instance cannot make kubernetes perceive that the interface instance fails; or after perceiving the interface failure, kubernetes is alarmed to trigger error handling events, and kubernetes can transfer traffic to a new Pod instance by scheduling a new Pod instance and the like. However, in this process, before kubernetes discovers that the instance traffic fails, and before the new Pod instance is successfully created, the old faulty instance will still bear the forwarding of uplink and downlink traffic, and if the CNI cannot provide high-reliability support for the Pod instance in this process, it will cause obvious flow interruption of the business, especially in a high-bandwidth, high-throughput, and low-latency sensitive network with a DPU card starting the hardware offload feature, even a very short time of flow interruption will cause massive packet loss and retransmission, which not only affects the business itself, but also exacerbates network congestion due to packet loss and retransmission, causing great losses. SUMMARY

[0004] Embodiments of the present application provide a DPU-based k8s cluster deployment method to improve the reliability of network communication of container instances in a cloud-native cluster.

[0005] In a first aspect, embodiments of the present application provide a DPU-based k8s cluster deployment method, comprising:

[0006] receiving a user-deployed container instance and determining two virtual function ports;

[0007] obtaining a first identifier of a device corresponding to the two virtual function ports, the two virtual function ports belonging to different physical function ports, and calling a container network interface plug-in, the container network interface plug-in being used to create a logically bound virtual function port, and the logically bound virtual function port working in a master-slave mode;

[0008] adding the two virtual function ports to the logically bound virtual function port according to the first identifier; adding the logically bound virtual function port to a kernel namespace of a container, the logically bound virtual function port being a network interface of the container;

[0009] allocating an IP address and a MAC address for the network interface of the container through a controller plug-in of a software-defined network;

[0010] sending the first identifier, the first identifier being used to create a logically bound virtual function representative port;

[0011] According to the first identifier and a second identifier corresponding to the physical function port, two corresponding virtual function representative ports are added as sub-interfaces to the logical binding virtual function representative port, and a working mode of the logical binding virtual function representative port is set to master-slave mode;

[0012] A logical binding uplink interface is created, and two uplink interfaces corresponding to the two physical function interfaces are added as sub-interfaces to the logical binding uplink interface according to the first identifier and the second identifier, and a working mode of the logical binding uplink interface is set to master-slave mode;

[0013] The logical binding virtual function representative port and the logical binding uplink interface are added to an OVS bridge;

[0014] OVS configuration information of the container-related flow table, the logical binding virtual function representative port and the logical binding uplink interface is obtained;

[0015] The container-related flow table and the OVS configuration information are downloaded to an OVS instance.

[0016] In a possible implementation, the two virtual function ports include a first virtual function port and a second virtual function port, and resource pools corresponding to the first virtual function port and the second virtual function port are different.

[0017] In a possible implementation, the first identifier includes 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.

[0018] In a possible implementation, the container network interface plugin is used to create the logical binding virtual function port for the container instance according to a CRD resource definition when the container instance is scheduled by a worker node.

[0019] In a second aspect, an embodiment of the present application provides a DPU-based k8s cluster deployment device, including:

[0020] A receiving module is configured to receive a container instance deployed by a user and determine two virtual function ports.

[0021] A first obtaining module is configured to obtain a first identifier of a device corresponding to the two virtual function ports, the two virtual function ports belong to different physical function ports, and a container network interface plugin is called, the container network interface plugin is used to create a logical binding virtual function port, and a working mode of the logical binding virtual function port is master-slave mode.

[0022] a first adding module, configured to add the two virtual function ports into the logical binding virtual function port according to the first identifier; and add the logical binding virtual function port into a kernel namespace of the container, the logical binding virtual function port being a network interface of the container;

[0023] a distribution module, configured to distribute an IP address and a MAC address for the network interface of the container through a controller plugin of a software defined network;

[0024] a first sending module, configured to send the first identifier, the first identifier being used to create a logical binding virtual function representative port;

[0025] a second adding module, configured to add two corresponding virtual function representative ports as sub-interfaces into the logical binding virtual function representative port according to the first identifier and a second identifier corresponding to the physical function port, the logical binding virtual function representative port being set in a master-slave mode;

[0026] a creating module, configured to create a logical binding uplink interface, and add two uplink interfaces corresponding to the two physical function interfaces as sub-interfaces into the logical binding uplink interface according to the first identifier and the second identifier, the logical binding uplink interface being set in a master-slave mode;

[0027] a third adding module, configured to add the logical binding virtual function representative port and the logical binding uplink interface into an OVS bridge;

[0028] a second obtaining module, configured to obtain an OVS configuration information of a flow table related to the container, the logical binding virtual function representative port and the logical binding uplink interface;

[0029] a second sending module, configured to send the flow table related to the container and the OVS configuration information to an OVS instance.

[0030] In a possible implementation, the two virtual function ports include a first virtual function port and a second virtual function port, and the first virtual function port and the second virtual function port correspond to different resource pools.

[0031] In a possible implementation, the first identifier includes a third identifier and a fourth identifier, the third identifier corresponding to the first virtual function port, and the fourth identifier corresponding to the second virtual function port.

[0032] In a possible implementation, the container network interface plugin is configured to create the logical binding virtual function port for the container instance according to a CRD resource definition when the container instance is scheduled by a worker node.

[0033] In a third aspect, the embodiments of the present application further provide an electronic device, comprising:

[0034] at least one processor;

[0035] and a memory in communication connection with the at least one processor;

[0036] The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the electronic device to perform the k8s cluster deployment method corresponding to any of the embodiments of the first aspect of the present application.

[0037] In a fourth aspect, the embodiments of the present application further provide a computer readable storage medium, which stores computer execution instructions, and the computer execution instructions are executed by a processor to implement the k8s cluster deployment method according to any of the embodiments of the first aspect of the present application.

[0038] In a fifth aspect, the present disclosure further provides a computer program product, which comprises computer execution instructions, and the computer execution instructions are executed by a processor to implement the k8s cluster deployment method according to any of the embodiments of the first aspect of the present disclosure.

[0039] In summary, the method shown in the embodiments of the present application can bind two virtual interfaces belonging to different physical interfaces into master-slave mode interfaces when a single virtualized SRIOV virtual interface fails, so that the network traffic forwarding of the container instance in the cloud native network will be interrupted. When the master device virtual function fails, it can be switched to the slave device to improve the disaster recovery fault tolerance capability. It can solve the problem of flow interruption when a single VF interface is allocated to a Pod and the software and hardware problems fail in the existing scheme, thereby improving the reliability of network communication of the Pod instance in the cloud native cluster. BRIEF DESCRIPTION OF DRAWINGS

[0040] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the present disclosure and, together with the specification, serve to explain the principles of the present disclosure.

[0041] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced as follows. Obviously, those skilled in the art can obtain other drawings according to these drawings without any creative effort.

[0042] Figure 1 A schematic diagram of the k8s cluster deployment structure of the DPU provided by the embodiments of the present application;

[0043] Figure 2A flowchart of a method for deploying a k8s cluster based on a DPU is provided for an embodiment of the present application.

[0044] Figure 3 A schematic diagram of a device for deploying a k8s cluster based on a DPU is provided for an embodiment of the present application.

[0045] Figure 4 A device for deploying a k8s cluster based on a DPU is provided for an embodiment of the present application. DETAILED DESCRIPTION

[0046] The following description refers to the accompanying drawings. Unless otherwise noted, like elements in different drawings have the same or similar notation, and the same or similar elements in different drawings are represented with the same or similar reference numerals. The detailed description of illustrative embodiments described herein provides examples, and the scope of embodiments of the present application is not limited to these examples. Certain embodiments of the present application are described herein with reference to the accompanying drawings.

[0047] The following specific embodiments can be combined with each other, and some embodiments may not be described again for the same or similar concepts or processes. The embodiments of the present application will be described below with reference to the accompanying drawings.

[0048] It should be noted that, in this document, relational terms such as "first" and "second", and the like, are used solely to distinguish one entity or action from another entity or action, without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element preceded by "comprises... " does not, without more constraints, foreclose the existence of additional identical elements in the process, method, article, or apparatus that comprises the recited element.

[0049] The following exemplary explanations are provided for the terms related to the present application.

[0050] Cloud Native, Cloud Native technology is to help organizations build and run scalable applications in new dynamic environments such as public clouds, private clouds and hybrid clouds. Representative technologies of Cloud Native include containers, service mesh, microservices, immutable infrastructure and declarative APIs. These technologies can build loosely coupled systems with good fault tolerance, easy management and easy observation. Combined with reliable automation, Cloud Native technology enables engineers to easily make frequent and predictable major changes to the system.

[0051] DPU: Data Processing Unit, a dedicated hardware accelerator for data-centric computing processors, integrates complete data center functions on a single chip, and together with CPU and GPU forms the three pillars of new computing. By using specially designed hardware accelerators, data packets entering the DPU can be processed quickly, reducing processing delay and improving processing throughput.

[0052] K8S: Its full name is kubernetes, and K8S is its abbreviation, replacing the 8 characters of "ubernete" with "8". 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 provides a series of functions to simplify application deployment, scheduling, self-healing and scaling.

[0053] SOC: System On Chip, System On Chip, means it is a product, a dedicated target integrated circuit, which contains a complete system and all embedded software. DPU SoC is not a node resource of the kubernetes cluster, but only as an independent operating system used on the DPU network card to run software programs.

[0054] CNI / cni: Container Network Interface, the full name of the container network interface, is used to implement a network model for multi-container communication, responsible for creating and managing network interfaces for containers, including allocating IP addresses, configuring routes, setting network policies, etc. CNI plugins can implement these functions according to different network implementations, such as using Linux bridges, VLANs, Overlay networks, etc.

[0055] pod: Point of Delivery, Kubernetes encapsulates one or more containers into a high-level structure of a pod. Any containers in the same pod will share the same namespace and local network. Containers can easily communicate with other containers in the same container, maintaining a certain degree of isolation as if they were on the same machine.

[0056] crd: CustomResourceDefinition, the English abbreviation for Custom Resource Definition, is used to manage the configuration of a pod resource. For example, a pod corresponds to the configuration of a crd.

[0057] PF / pf: is the abbreviation of Physical Funtion, which refers to the actual function of the physical network card, which can directly interact with the physical network. PF is responsible for managing and controlling resources related to VF, and processing communication between VFs.

[0058] OVN: Open Virtual Network, an open-source virtualization network project, uses OVS as the underlying technology, provides a flexible and programmable data path between the kernel and user space, and realizes the network interconnection of virtual machines and containers. It provides rich network functions and easy-to-use management interfaces, allowing users to build and manage complex virtual network environments.

[0059] OVS: OpenvSwitch, a high-quality, multi-layer virtual forwarding software. Its purpose is to support large-scale network automation through programming, while also supporting standard management interfaces and protocols.

[0060] ovn-kubernetes: a Kubernetes CNI based on OVN (Open Virtual Network), which provides an efficient, reliable, and flexible network solution to meet the communication needs between containers and between containers and external networks in Kubernetes clusters. In the DPU scenario, the forwarding plane ovs is offloaded to the DPU Soc, and ovn-kubernetes guides the ovs forwarding plane on the DPU Soc to forward traffic by converting the network information and service information of the entire K8s cluster into openflow flow table form.

[0061] SRIOV: Single Root Virtualization, which divides the network card into virtual functions VF and physical functions PF. SRIOV CNI, that is, the interface on the work node with SRIOV function.

[0062] Bond: Bond port is a network technology mainly used to bind multiple physical network cards to a logical network card, which can achieve link redundancy, bandwidth expansion, load balancing, etc. Bond port technology is mainly used in production scenarios with high network throughput and high network stability requirements, and is a common technology to improve performance and reliability.

[0063] Figure 1 A k8s cluster deployment structure diagram of a DPU is provided for the embodiments of the present application. In the k8s cluster deployment structure diagram of the DPU, the DPU is connected to the host through the SRIOV network card, and the SRIOV network card is connected to the host through the Bond port. Figure 1In the specific implementation, the hardware and the software are deployed respectively. In the hardware deployment, the DPU network card is installed on the cloud server node in the data center, and provides a high-bandwidth, low-latency heterogeneous network computing acceleration engine for the cloud server node.

[0064] In the software deployment, the SRIOV CNI is deployed on the control node and the worker node of the k8s cluster, and PF and VF resource pools are defined and created for the container pod instance of the cluster. The network container interface Bond CNI is deployed on each worker node of the k8s cluster, and the Bond CNI is used to create a logical bond virtual function bond VF interface for a container pod instance according to a user-defined resource definition (Custom Resource Definition, CRD) when the container pod instance is scheduled on a worker node. The PF resource pool that can be used and the VF resource pool that can be allocated for each PF are configured through the CRD related to the Bond CNI. The related components of the ovn-kubernetes CNI are deployed on the control node, the worker node and the DPU SoC of the kubernetes cluster, and are used to provide basic network capabilities for the kubernetes cluster.

[0065] In the specific implementation, the hardware and the software are deployed respectively. In the hardware deployment, the DPU network card is installed on the cloud server node in the data center, and provides a high-bandwidth, low-latency heterogeneous network computing acceleration engine for the cloud server node.

[0066] The worker node of the kubernetes cluster deploys the ovn-kubernetes CNI component.

[0067] The DPU SoC deploys the OVN Controller and the OVN SoC module.

[0068] The control node and the worker node of the kubernetes cluster deploy the Multus CNI, which is used to provide the cooperation capability of the SRIOV CNI, the Bond CNI and the ovn-kubernetes CNI for the kubernetes.

[0069] In the specific implementation, the hardware and the software are deployed respectively. In the hardware deployment, the DPU network card is installed on the cloud server node in the data center, and provides a high-bandwidth, low-latency heterogeneous network computing acceleration engine for the cloud server node. Figure 1 In the specific implementation, the hardware and the software are deployed respectively. In the hardware deployment, the DPU network card is installed on the cloud server node in the data center, and provides a high-bandwidth, low-latency heterogeneous network computing acceleration engine for the cloud server node.

[0070] No. 2 represents: Device IDs, i.e. device identifiers.

[0071] No. 3 represents: Create bond port, i.e. creating a Bond port.

[0072] No. 4 represents: set port to pod NS, i.e. adding the created Bond port to the namespace kernel namespace of the Pod.

[0073] No. 5 represents: get PF IDs and VF IDs, i.e. obtaining PF IDs and VF IDs

[0074] No. 6 represents: Create bond vfr port and bond uplink port with Active-standby mode, and add the two bond ports on OVS bridge, i.e. setting the bond vfr port and the bond uplink port to the master-slave working mode, and adding them to the OVS bridge.

[0075] No. 7 represents: Synchronize the openflow tables relates to the bond VF port from OVN DB, i.e. synchronizing the bond VF interface related openflow flow table information from the OVN DB.

[0076] No. 8 represents: Download the openflow tables related to the bond port, i.e. downloading the synchronized bond port flow table information to the OVS instance.

[0077] No. 9 represents: miss up call, i.e. missing up call event.

[0078] No. 10 represents: Download hw_offloaded tables, i.e. downloading hardware offloaded tables.

[0079] Figure 2 A k8s cluster deployment method based on DPU provided by an embodiment of the present application is shown in a flowchart. In Figure 2 , steps S201 to S210 are included. Each step is described in detail as follows.

[0080] Step S201, receiving a container instance deployed by a user, and determining two virtual function ports.

[0081] In a possible implementation, the two virtual function ports include a first virtual function port and a second virtual function port, and the first virtual function port and the second virtual function port correspond to different resource pools.

[0082] It can be understood that the kubernetes receives a user to deploy a container Pod instance, and the kubelet calls the SRIOV CNI to select two physical function ports PF from a physical function port PF resource pool available on a worker node, and then select one virtual function port VF in a SRIOV VF resource pool corresponding to each PF. The two virtual function ports VF include a first virtual function port and a second virtual function port, and the first virtual function port and the second virtual function port correspond to different resource pools.

[0083] In a possible implementation, the first identifier includes 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.

[0084] It can be understood that the first identifier here refers to the identifiers of the two devices, that is, the first identifier includes a third identifier and a fourth identifier, and the identifier of each device corresponds to a different virtual function port. That is, 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 a unique PCI bus address corresponding to the virtual function port VF in the operating system, or other addresses, but generally uses the PCI bus address in implementation.

[0085] In step S202, a first identifier of devices corresponding to the two virtual function ports is obtained, the two virtual function ports belong to different physical function ports, and a container network interface plug-in is called, the container network interface plug-in is used to create a logical binding virtual function port, and the working mode of the logical binding virtual function port is a master-slave mode.

[0086] In a possible implementation, the container network interface plug-in is used to create the logical binding virtual function port for the container instance according to a CRD resource definition when the container instance is scheduled by a worker node.

[0087] In step S203, the two virtual function ports are added to the logical binding virtual function port according to the first identifier; and the logical binding virtual function port is added to a kernel namespace of a container, and the logical binding virtual function port is a network interface of the container.

[0088] Step S204, the controller plugin of the software-defined network allocates IP and MAC addresses for the network interface of the container.

[0089] It can be understood that the kubernetes obtains the identifiers of the devices corresponding to the two virtual function ports (VF device IDs) allocated, and calls a container network interface plugin (Bond CNI). The Bond CNI creates a logical bond virtual function port (bond VF port), and adds the two virtual function ports (VF) selected as sub-interfaces to the bond VF port according to the VF device IDs (identifiers of the devices corresponding to the VF, i.e. the first identifiers), and sets the bond mode to Active-Standby master-slave mode.

[0090] It can be understood that the kubelet calls the ovn-kubernetes CNI (controller plugin of the OV K8s software-defined network) to add the created bond VF port to the kernel namespace (namespace) of the Pod, and the logical bond virtual function port serves as the network interface (NIC) of the Pod. The controller plugin of the OV K8s software-defined network allocates IP and MAC addresses for the network interface of the container.

[0091] Step S205, the first identifier is sent, and the first identifier is used to create a logical bond virtual function representative port.

[0092] It can be understood that this step is to send the first identifier to the system-on-chip module deployed on the DPU, and the first identifier is used to create a logical bond virtual function representative port.

[0093] Step S206, according to the first identifier and the second identifier corresponding to the physical function port, the two virtual function representative ports corresponding to the two physical function ports are added as sub-interfaces to the logical bond virtual function representative port, and the working mode of the logical bond virtual function representative port is set to master-slave mode.

[0094] Step S207, a logical bond uplink interface is created, and the two uplink interfaces corresponding to the two physical function interfaces are added as sub-interfaces to the logical bond uplink interface according to the first identifier and the second identifier, and the working mode of the logical bond uplink interface is set to master-slave mode.

[0095] It can be understood that after the DPU system-on-chip module (OVN SoC module) of the OV DPU receives the identifiers PF ID and VF ID, two bond interfaces are created, wherein the bond interface includes a vfr port and an uplink interface.

[0096] In a possible implementation, a logical bond virtual function representor port (bond vfr port) is created on the DPU SoC, and two VF representor VFr (VF representor) corresponding to the obtained PF ID and VF ID are added as sub-interfaces to the bond vfr port, and the bond port mode is set to Active-standby master-slave mode.

[0097] In another possible implementation, a logical bond uplink interface (bond uplink) is created on the DPU SoC, and two uplink interfaces corresponding to the two PF interfaces according to the obtained PF ID are added as sub-interfaces to the bond uplink interface, and the bond port mode is set to Active-standby master-slave mode.

[0098] In step S208, the logical bond virtual function representor port and the logical bond uplink interface are added to the OVS bridge.

[0099] It can be understood that the two bond interfaces are added to the OVS bridge, that is, the logical bond uplink interface (bond uplink) and the logical bond virtual function representor port (bond vfr port) are added to the OVS bridge.

[0100] In step S209, the OVS configuration information of the container-related flow table, the logical bond virtual function representor port, and the logical bond uplink interface is obtained.

[0101] In step S210, the container-related flow table and the OVS configuration information are pushed to the OVS instance.

[0102] It can be understood that the OVN Controller component deployed on the DPU Soc synchronously obtains the latest flow table related to the newly created container Pod and the bond VF interface related configuration in the Kubernetes cluster network from the OVN Control Center component. The OVN Controller component pushes the openflow flow table information related to the newly created Pod and the bond VF interface to the OVS instance.

[0103] When there is a data stream related to the created Pod instance arrives at the DPU network card, the ASIC hardware forwarding engine fails to forward due to the lack of flow-related information, triggers a table item missing up call, and sends the first packet to the OVS instance on the DPU SoC. The OVS instance forwards the packet according to the openflow flow table information and related flow table.

[0104] After the first packet is forwarded, the OVS instance on the DPU SoC issues the hardware offload table item related to the flow to the ASIC hardware forwarding engine, and the subsequent packets can be directly forwarded by hardware table lookup.

[0105] In the embodiment of the application, the identifier of the device corresponds to the identifier of the VF, and then the first identifier can be used to refer to the identifier of the device or the identifier of the VF. In addition, the identifier of the device can be identified by the first identifier, and the identifier of the VF can be described by the fifth identifier, which includes the sixth identifier and the seventh identifier. In related steps, they can be used interchangeably, such as "sending the first identifier", which can also be described as "sending the fifth identifier", "according to the first identifier and the second identifier corresponding to the physical function port", which can also be described as "according to the fifth identifier and the second identifier corresponding to the physical function port"

[0106] It can be understood that the above-described scheme embodiment is an example of an ASIC DPU network card, but the application can also be applied to any network card supporting SRIOV features and network traffic hardware offload capabilities, such as a SmartNIC intelligent network card. The embodiments of the present application do not limit this.

[0107] The embodiment of the present application takes kubernetes as an example as a cloud-native orchestration tool, and the application is also applicable to other cloud-native cluster orchestration tools, such as openshift. The embodiments of the present application do not limit this.

[0108] The embodiment of the present application takes Pod as an example of kubernetes scheduling instance, and the application is also applicable to VM and bare metal instances managed by kubernetes. The embodiments of the present application do not limit this.

[0109] The embodiment of the present application takes ovn-kubernetes CNI as an example of CNI for providing network interface for kubernetes cluster, and the application is also applicable to any open source or self-developed CNI based on SDN controller / forwarding plane, such as kube-ovn, Antrea, etc. The embodiments of the present application do not limit this.

[0110] In summary, the method shown in the embodiments of the present application can bind two virtual interfaces belonging to different physical interfaces into a master-slave mode interface, and can switch to the slave device when the master device virtual function fails, so as to improve the disaster recovery fault tolerance capability. The flow interruption problem caused by the failure of the single VF interface allocated to the Pod in the existing scheme can be solved, thereby improving the reliability of the network communication of the Pod instance in the cloud native cluster.

[0111] Figure 3 A DPU-based k8s cluster deployment device provided by the embodiments of the present application is shown in a schematic diagram, which includes the following modules:

[0112] The receiving module 301 is configured to receive a container instance deployed by a user and determine two virtual function ports;

[0113] The first obtaining module 302 is configured to obtain a first identifier of a device corresponding to the two virtual function ports, the two virtual function ports belong to different physical function ports, and call a container network interface plug-in, the container network interface plug-in is configured to create a logically bound virtual function port, and the working mode of the logically bound virtual function port is a master-slave mode;

[0114] The first adding module 303 is configured to add the two virtual function ports into the logically bound virtual function port according to the first identifier; add the logically bound virtual function port into a kernel namespace of a container, and the logically bound virtual function port is a network interface of the container;

[0115] The allocation module 304 is configured to allocate an IP address and a MAC address for the network interface of the container through a controller plug-in of a software-defined network;

[0116] The first sending module 305 is configured to send the first identifier, and the first identifier is used to create a logically bound virtual function representative port;

[0117] The second adding module 306 is configured to add the two virtual function representative ports corresponding to the first identifier and the second identifier of the physical function port as sub-interfaces into the logically bound virtual function representative port, and the working mode of the logically bound virtual function representative port is set to a master-slave mode;

[0118] The creating module 307 is configured to create a logically bound uplink interface, and add two uplink interfaces corresponding to the two physical function interfaces as sub-interfaces into the logically bound uplink interface according to the first identifier and the second identifier, and the working mode of the logically bound uplink interface is set to a master-slave mode;

[0119] The third adding module 308 is configured to add the logical binding virtual function representative port and the logical binding uplink interface to the OVS bridge.

[0120] The second obtaining module 309 is configured to obtain OVS configuration information of the container-related flow table, the logical binding virtual function representative port and the logical binding uplink interface.

[0121] The second sending module 310 is configured to send the container-related flow table and the OVS configuration information to an OVS instance.

[0122] In a possible implementation, the two virtual function ports include a first virtual function port and a second virtual function port, and the first virtual function port and the second virtual function port correspond to different resource pools.

[0123] In a possible implementation, the first identifier includes 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.

[0124] In a possible implementation, the container network interface plug-in is configured to create the logical binding virtual function port for the container instance according to a CRD resource definition when the container instance is scheduled by a worker node.

[0125] It can be understood that the apparatus provided by the embodiments of the present application is used to implement Figure 2 all the methods provided by the embodiments.

[0126] Figure 4 A structural schematic diagram of an electronic device provided by an embodiment of the present application is shown in Figure 4 The electronic device 400 includes a memory 410 and a processor 420.

[0127] The memory 410 stores a computer program executable by the at least one processor 420. The computer program is executed by the at least one processor 420, so that the electronic device implements the method provided in any one of the above embodiments.

[0128] The memory 410 and the processor 420 can be connected through a bus 430.

[0129] The related description can be understood by referring to the related description and effects of the method embodiments, which will not be repeated here.

[0130] An embodiment of the present application provides a computer readable storage medium, which stores a computer program. The computer program is executed by a processor to implement the method of any corresponding embodiment. Figure 2 ​

[0131] The computer readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disc, and an optical data storage device, etc.

[0132] An embodiment of the present application provides a computer program product, comprising computer execution instructions, which are executed by a processor to implement the method of any of the embodiments. Figure 2 The method of any of the embodiments.

[0133] In several embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented in other ways. For example, the apparatus embodiment described above is only schematic, for example, the division of the modules is only a logical function division, and in actual implementation, there can be another division manner, for example, a plurality of modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed each other can be indirect coupling or communication connection through some interface, apparatus or module, and can be electrical, mechanical or other forms.

[0134] Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed. It is intended that the present application cover any and all variations of the application that come within the scope of the claims and a concept underlying the application. It is intended that the specification and examples be considered exemplary only, with the true scope of the application being indicated by the following claims.

[0135] It should be understood that the application is not limited to the precise construction that has been described above and shown in the accompanying drawings, and that various modifications and changes can be effected therein by those skilled in the art without departing from the scope of the application.

Claims

1. A k8s cluster deployment method based on DPU, characterized in that: include: Receive the container instance deployed by the user and determine two virtual function ports; Obtaining first identifiers of devices corresponding to the two virtual function ports, where the two virtual function ports belong to different physical function ports, and calling a container network interface plug-in, where the container network interface plug-in is used to create a logically bound virtual function port, wherein the creation of the logically bound virtual function port operates in a master-slave mode; adding the two virtual function ports to the logically bound virtual function port according to the first identifier; adding the logically bound virtual function port to the kernel namespace of the container, the logically bound virtual function port being the network interface of the container; Assigning an IP address and a MAC address to the network interface of the container through a software-defined network controller plug-in; Sending the first identifier, where the first identifier is used to create a logically bound virtual function representative interface; According to the first identifier and the second identifier corresponding to the physical function port, the corresponding two virtual function representative ports are added as sub-interfaces to the logically bound virtual function representative port, and the working mode of the logically bound virtual function representative port is set to master-slave mode; Create a logically bound uplink interface, and add the two uplink interfaces corresponding to the physical functional port as sub-interfaces to the logically bound uplink interface according to the first identifier and the second identifier, and set the working mode of the logically bound uplink interface to master-slave mode; Add the logically bound virtual function representative port and the logically bound uplink interface to the OVS bridge; Obtain OVS configuration information of the flow table related to the container, the logically bound virtual function representative port, and the logically bound uplink interface; The flow table related to the container 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 include a first virtual function port and a second virtual function port, and the first virtual function port and the second virtual function port correspond to different resource pools.

3. The method according to claim 2, characterized in that The first identifier includes 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.

4. The method according to any one of claims 1 to 3, characterized in that The container network interface plug-in is used to create the logical binding virtual function port for the container instance according to the CRD resource definition when the container instance is scheduled by the working node.

5. A k8s 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 two virtual function ports; A first acquisition module is configured to acquire first identifiers of devices corresponding to the two virtual function ports, the two virtual function ports belonging to different physical function ports, and call a container network interface plug-in, the container network interface plug-in is configured to create a logically bound virtual function port, wherein the creation of the logically bound virtual function port operates in a master-slave mode; a first adding module, configured to add the two virtual function interfaces to the logically bound virtual function interface according to the first identifier; Adding the logically bound virtual function port to the kernel namespace of the container, wherein the logically bound virtual function port is the network interface of the container; an allocation module, configured to allocate an IP address and a MAC address to a network interface of the container through a controller plug-in of a software-defined network; A first sending module, configured to send the first identifier, where the first identifier is used to create a logically bound virtual function representative interface; A second adding module is used to add the corresponding two virtual function representative ports as sub-interfaces to the logical binding virtual function representative port according to the first identifier and the second identifier corresponding to the physical function port, and the working mode of the logical binding virtual function representative port is set to master-slave mode; A creation module is used to create a logically bound uplink interface, and add the two uplink interfaces corresponding to the physical functional port as sub-interfaces to the logically bound uplink interface according to the first identifier and the second identifier, and the working mode of the logically bound uplink interface is set to master-slave mode; A third adding module is used to add the logical binding virtual function representative port and the logical binding uplink interface to the OVS bridge; A second acquisition module is used to obtain OVS configuration information of the flow table related to the container, the logically bound virtual function representative port and the logically bound uplink interface; The second sending module is used to send the flow table related to the container and the OVS configuration information to the OVS instance.

6. The device according to claim 5, characterized in that The two virtual function ports include a first virtual function port and a second virtual function port, and the first virtual function port and the second virtual function port correspond to different resource pools.

7. The device according to claim 6, characterized in that The first identifier includes 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.

8. The device according to any one of claims 5 to 7, characterized in that: The container network interface plug-in is used to create the logical binding virtual function port for the container instance according to the CRD resource definition when the container instance is scheduled by the working node.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 4 when executed by a processor.

10. A computer program product comprising computer-executable instructions, characterized in that: When the computer-executable instructions are executed by a processor, the computer-executable instructions are used to implement the method according to any one of claims 1 to 4.

Images