Dpu-based network path alive detection method, worker node, device and medium

Abstract

The application relates to a DPU-based network path alive detection method, a working node, equipment and a medium, in particular to the network processing technical field. The method is applied to a working node, the working node comprises a container group, a first container network interface (CNI) plug-in and a DPU network card comprising a virtual switch, and the working node further comprises a second CNI plug-in; the method comprises the following steps: when the container group is running, sending container group information and corresponding virtual function (VF) network port information to the second CNI plug-in through the first CNI plug-in; configuring a single-arm echo message according to the container group information through the second CNI plug-in, and sending the single-arm echo message through a VF network port indicated by the VF network port information, the destination address of the single-arm echo message being the same as the source address; in the case that the second CNI plug-in detects a response message of the single-arm echo message, it is determined that a network path corresponding to the VF network port is connected. The application solves the problem of network path fault detection after the working node introduces the DPU.

Description

Technical Field

[0001] This application relates to the field of network processing technology, and in particular to a network path detection method, working node, device and medium based on DPU, as well as a computer program product for implementing the network path detection method based on DPU. Background Technology

[0002] Container clusters introduce Data Processing Units (DPUs) as a hardware offloading technology. This allows data processing tasks to be transferred from the Central Processing Unit (CPU) of worker nodes to a dedicated DPU, thereby freeing up the CPU to focus on core application processing and improving the system performance and efficiency of worker nodes.

[0003] When DPU is introduced as a hardware offloading technology, the traffic path on the worker node can be represented as: VNIC→VF→VFR→ovs→physical network interface, while the traditional traffic path on the worker node is: VNIC→kernel network interface→physical network interface. The introduction of DPU lengthens the traffic path, increasing the likelihood of failures and consequently making fault location more difficult. Therefore, how to detect the connectivity of the network path from VF to VFR is a pressing technical problem to be solved in this field. Summary of the Invention

[0004] To address or at least partially address the aforementioned technical problems, this application provides a network path detection method, working node, device, and medium based on a DPU, capable of detecting the connectivity of a network path from VF to VFR.

[0005] To achieve the above objectives, the technical solutions provided in this application are as follows:

[0006] Firstly, this application provides a network path probing method based on a DPU, applied to a worker node. The worker node includes a container group, a first container network interface (CNI) plugin, and a DPU network interface card including a virtual switch. The worker node also includes a second CNI plugin. The method includes: when the container group is running, sending container group information and corresponding Virtual Function (VF) port information to the second CNI plugin through the first CNI plugin; configuring a single-arm echo message according to the container group information through the second CNI plugin, and sending the single-arm echo message through the VF port indicated by the VF port information, wherein the destination address and source address of the single-arm echo message are the same; and determining that the network path corresponding to the VF port is connected when the second CNI plugin detects a response message to the single-arm echo message.

[0007] As an optional implementation of this application, after configuring a single-arm echo message according to the container group information through the second CNI plugin and sending the single-arm echo message through the VF port indicated by the VF port information, the method further includes: marking the network path corresponding to the VF port as faulty if the second CNI plugin does not detect a response message for the single-arm echo message.

[0008] As an optional implementation of this application, the container group information includes the virtual network interface (VNIC) address of the container group; configuring a single-arm echo message according to the container group information through a second CNI plugin, and sending the single-arm echo message through the VF port indicated by the VF port information, includes: configuring the destination address and source address of the single-arm echo message to be the VNIC address of the container group through the second CNI plugin; and sending the single-arm echo message through the VF port indicated by the VF port information.

[0009] As an optional implementation of this application, before sending the container group information and the corresponding Virtual Function (VF) network interface information to the second CNI plugin through the first CNI plugin when the container group is running, the method further includes: configuring the single-arm echo protocol for the VF network interface corresponding to the container group through the second CNI plugin when the container group starts.

[0010] As an optional implementation of this application, after configuring a single-arm echo message according to the container group information through the second CNI plugin, and sending the single-arm echo message through the VF port indicated by the VF port information, and before determining that the network path corresponding to the VF port is connected when the second CNI plugin detects the response message of the single-arm echo message, the method further includes: sending a response message to the VFR port corresponding to the VF port through a virtual switch, wherein the source address and destination address of the response message are the same, which is the virtual network interface (VNIC) address of the container group.

[0011] As an optional implementation of this application, before sending the container group information and the corresponding Virtual Function Representative (VF) port information to the second CNI plugin through the first CNI plugin during container runtime, the method further includes: when the container group is scheduled to a worker node, selecting a VF port for the container group and requesting the control node to change the container resources so that the control node can create a Logical Switch Port LSP incremental entry carrying the VF port information in the northbound database; listening to the northbound database through the client controller on the DPU network card; after the client controller listens to the resource synchronization request sent by the northbound database, the resource synchronization request includes the LSP incremental entry, and in response to the resource synchronization request, adding the Virtual Function Representative (VFR) port corresponding to the VF port information to the virtual switch through the client controller.

[0012] Secondly, this application provides a working node, which includes a container group, a first CNI plugin, and a DPU network interface card including a virtual switch. The working node also includes a second CNI plugin, wherein: the first CNI plugin is used to send container group information and corresponding Virtual Function (VF) port information to the second CNI plugin when the container is running; the second CNI plugin is used to configure a single-arm echo message according to the container group information, and send the single-arm echo message through the VF port indicated by the VF port information, wherein the destination address of the single-arm echo message is the same as the source address; and upon detecting a response message of the single-arm echo message, it is determined that the network path corresponding to the VF port is connected.

[0013] Thirdly, this application provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein when the computer program is executed by the processor, it implements the DPU-based network path detection method as described in the first aspect or any of its optional embodiments.

[0014] Fourthly, this application provides a computer-readable storage medium, comprising: storing a computer program on the computer-readable storage medium, wherein when the computer program is executed by a processor, it implements the DPU-based network path detection method as described in the first aspect or any of its optional embodiments.

[0015] Fifthly, this application provides a computer program product, comprising: the computer program product including a computer program, which, when run on a computer, causes the computer to implement the DPU-based network path detection method as described in the first aspect or any of its optional embodiments.

[0016] The technical solution provided in this application has the following advantages compared with the prior art:

[0017] This application provides a network path liveness detection method, worker node, device, and medium based on DPU. The method is applied to a worker node with a second CNI plugin deployed. During container group operation, a first CNI plugin sends container group information and corresponding VF interface information to the second CNI plugin. Then, the second CNI plugin configures a single-arm echo message with the same destination and source addresses based on the container group information and sends this single-arm echo message through the VF interface. If the second CNI plugin detects a response message for the single-arm echo message, it can determine that the network path corresponding to the VF interface is connected. Thus, this application uses single-arm echo messages to dynamically detect network path connectivity for liveness detection, enabling rapid fault location and facilitating efficient worker node operation. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the 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.

[0020] Figure 1 A schematic diagram of existing network path liveness detection methods;

[0021] Figure 2 A flowchart illustrating a DPU-based network path liveness detection method provided in this application embodiment. Figure 1 ;

[0022] Figure 3A A schematic diagram of the DPU-based network path detection method provided in this application embodiment. Figure 1 ;

[0023] Figure 3B A schematic diagram of the DPU-based network path detection method provided in this application embodiment. Figure 2 ;

[0024] Figure 3C Schematic diagram 3 of the DPU-based network path detection method provided in the embodiments of this application;

[0025] Figure 4 This is a flowchart illustrating a network path detection method based on DPU according to an embodiment of this application. Figure 2 ;

[0026] Figure 5 A schematic diagram of the structure of a working node provided in an embodiment of this application;

[0027] Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0028] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the technical terms used in the description of the embodiments or the prior art will be briefly introduced below:

[0029] Kubernetes, also known as K8s, is an open-source system for automating the deployment, scaling, and management of containerized applications. It groups the containers that make up an application into logical units for easier management and service discovery. Kubernetes is commonly used to build multi-Container Network Interface (CNI) networks. Linux containers provide a lightweight virtualization approach, allowing multiple virtual environments (containers) to run simultaneously on a single host. Containers provide virtualization at the operating system level, where the kernel controls isolated containers.

[0030] Data Processing Units (DPUs) are a major category of newly developed dedicated processors. Following CPUs and GPUs, they are the third crucial computing chip in data center scenarios, providing a computing engine for high-bandwidth, low-latency, and data-intensive computing environments. They are data-centric, I / O-intensive, and utilize software-defined technologies to support infrastructure resource layer virtualization. This next-generation computing chip improves computing system efficiency, reduces the overall system cost of ownership, enhances data processing performance, and reduces performance overhead on other computing chips. DPU network interface cards (NICs) are installed on cloud server nodes in data centers, providing a high-bandwidth, low-latency heterogeneous network computing acceleration engine. After correctly installing a DPU NIC on a node, the DPU NIC resources appear in the node's kernel network space as VF and PF ports.

[0031] A system-on-chip (SoC) DPU is an operating system deployed on the DPU network interface card.

[0032] etcd is an open-source, distributed key-value store used to store and manage critical information needed to keep distributed systems running. It can be likened to a catalog of books in a large library, recording information about all resources in the cluster and managing Kubernetes configuration data, state data, and metadata. etcd provides a single, consistent source of truth about the system's state at any given point in time, including all clusters and container groups and the application instances within them. etcd is the data repository used to create and maintain this version of truth.

[0033] Open vSwitch (OVS) is a software-based virtualized Ethernet switch that supports port mirroring, VLANs, and other network monitoring protocols. OVS operates in kernel mode and supports various standard management interfaces and protocols, as well as distributed environments across multiple physical servers. It provides support for the OpenFlow protocol, enabling integration with numerous open-source virtualization platforms. OpenFlow is a protocol that supports Software-Defined Networking (SDN).

[0034] A Pod is the smallest unit of deployment and management in a Kubernetes cluster, co-located and coordinated. A Pod contains one or more containers and the resources used to manage them; it is an abstract collection of one or more services (processes). Pods can share network and storage (it can be simply understood as a logical virtual machine, but it is not a virtual machine).

[0035] Kubelet is a proxy component / daemon on Kubernetes worker nodes that periodically receives new or modified Pod specifications from the Kubernetes API Server component and ensures that Pods and their containers run under the expected specifications. This component not only receives Pod updates from the API Server but also acts as a monitoring component for worker nodes, reporting the host's operational status to the Kubernetes API Server.

[0036] VF (Virtual Function) refers to PCI Express (PCIe) Virtual Function (VF), a lightweight PCIe function that supports single root I / O virtualization (SR-IOV).

[0037] ovn-kubernetes CNI, or Container Network Interface, is a CNCF project consisting of a set of specifications and libraries for configuring network interfaces for Linux containers, along with some plugins. CNI only concerns itself with network allocation during container creation and releasing network resources when the container is deleted. It provides an efficient, reliable, and flexible networking solution to meet the communication needs between containers in a Kubernetes cluster and between containers and external networks.

[0038] OVN is a lightweight SDN controller specifically designed for handling network transactions and performing network operations via SDN. OVN manages the mapping between logical and physical networks through the interaction of its Northbound Database (NBDB) and Southbound Database (SBDB), enabling flexible network configuration and management. Northbound Database: OVN's Northbound Database includes two clients: the OVN / CMS plugin and ovn-northd. ovn-northd connects the Northbound and Southbound Databases, translating logical network configurations from traditional network concepts into logical data path flows that the Southbound Database can understand. Southbound Database: As the central component of the system, the Southbound Database contains three types of data: physical network tables (specifying how to access the hypervisor and other nodes), logical network tables (describing logical networks using logical data path flows), and binding tables (linking the locations of logical network components to physical networks). In this way, OVN provides a centralized and scalable network management solution suitable for the network virtualization and automated deployment needs of cloud computing environments.

[0039] The control node (Master node) is the core control node in a distributed system or Kubernetes cluster, responsible for managing and controlling the operation and state of the entire cluster. It is the control center of the cluster, handling requests from clients such as creating, reading, updating, and deleting resources. The Master node manages and monitors the state of the entire cluster through its components, such as the API server, controller manager, scheduler, and etcd. These components work together to ensure the high availability, scalability, and stability of the cluster.

[0040] The Kubernetes API Server, as the core of the Kubernetes cluster, handles requests from worker nodes. Its primary purpose is to receive and process API calls in the form of HTTP requests. The Kubernetes API Server is a service provided by the kube-apiserver process running on the Master node. This service is the central hub for data interaction and communication between various functional modules within the cluster, serving as the data bus and data center for the entire system. Because the API Server handles critical data communication within the system, its performance directly impacts the overall cluster performance. The Kubernetes API Server's functions include: providing a REST API interface for cluster management (including authentication, authorization, data verification, and cluster state changes); serving as a hub for data interaction and communication between other modules (other modules query or modify data through the API Server, while only the API Server directly manipulates etcd); acting as the entry point for resource quota control; possessing a comprehensive cluster security mechanism; and acting like a checkout counter in a large supermarket, handling the buying, selling (creating, updating), and querying of various goods (resources).

[0041] like Figure 1 As shown, the current network path detection method includes the following steps:

[0042] Step 1: When a container group Pod is scheduled to a worker node, the daemon process Kubelet running on that worker node will select an available Virtual Function (VF) from the list of Virtual Functions (VFs) and send the VF information of the available VF to the container network interface ovn-kubernetes CNI.

[0043] The worker node maintains a list of Virtual Functions (VFs), which appears as network ports on the worker node. Correspondingly, the DPU SOC maintains a list of Virtual Function Representatives (VFRs), with each VFR corresponding to a VF.

[0044] The selected available VF will serve as the network interface for communication between the container group Pod and the outside world. The container group Pod can use the available VF to direct traffic to the corresponding VFR on the DPU SOC side, and finally transmit it to the virtual switch connected to the VFR.

[0045] Step 2: The Container Network Interface (ovn-kubernetes CNI) sends VF information to the Kubernetes API Server, a resource interface server running on the Master control node.

[0046] Step 3: The Kubernetes API Server stores VF information in the container namespace pod info of the distributed key-value store etcd.

[0047] This step treats the operation event (pod event) of the container namespace pod info as a creation event, which can be listened to by the OVS controller running on the DPU SOC on the worker node.

[0048] Step 4: The Kubernetes API Server transmits the pod event to the ovn-kubernetes controller.

[0049] Step 5: The ovn-kubernetes controller creates the LSP corresponding to the operation event pod event.

[0050] Step 6: The OVS controller listens to the pod event through the Kubernetes API Server and obtains the VF information carried by the pod event.

[0051] Step 7: The OVS controller connects the VFR corresponding to the VF information to the virtual switch OVS.

[0052] At this point, the DPU side has completed the configuration of CNI, offloaded the network interface, and established the transmission network path between the container group and the virtual switch OVS. The traffic path on the worker node NODE can be represented as: VNIC→VF→VFR→ovs→physical network port.

[0053] Compared to the traditional path of traffic on the NODE node: VNIC → kernel network interface → physical network interface, the traffic path is lengthened after the introduction of DPU. This increases the possibility of failure and the difficulty of locating the fault. Therefore, how to detect the connectivity of the network path from VF to VFR is a technical problem that urgently needs to be solved in this field.

[0054] To address some or all of the technical problems existing in related technologies, this application provides a network path liveness detection method, worker node, device, and medium based on DPU. The method is applied to a worker node deployed with a second CNI plugin. During container group operation, the first CNI plugin sends container group information and corresponding VF interface information to the second CNI plugin. Then, the second CNI plugin configures a single-arm echo message with the same destination and source addresses based on the container group information and sends this single-arm echo message through the VF interface. If the second CNI plugin detects a response message to the single-arm echo message, it can determine that the network path corresponding to the VF interface is connected. Thus, this application embodiment dynamically detects network path connectivity for liveness detection by sending and receiving single-arm echo messages through the second CNI plugin, enabling rapid fault location and facilitating efficient operation of the worker node.

[0055] To better understand the above-mentioned objectives, features, and advantages of this application, the solution of this application will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0056] Many specific details are set forth in the following description in order to provide a full understanding of this application, but this application may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some embodiments of this application, and not all embodiments.

[0057] The network path detection method based on DPU provided in this application embodiment can be implemented by a network configuration device or electronic device, including but not limited to vehicle terminals, servers, personal computers, laptops, tablets, and smartphones. The operating system of the electronic device can include Android, Apple's iOS, Microsoft's Windows operating system, etc., and this application embodiment does not limit this. The electronic device can run independently to implement this application, or it can connect to a network and implement this application through interactive operation with other computer devices in the network. The network where the electronic device is located includes, but is not limited to, the Internet, wide area networks, metropolitan area networks, local area networks, and virtual private networks (VPNs).

[0058] It should be noted that the protection scope of the network path detection method based on DPU described in this application embodiment is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, subtracting, or replacing steps in the prior art based on the principles of this application is included within the protection scope of this application.

[0059] like Figure 2 As shown, Figure 2 A flowchart illustrating a DPU-based network path liveness detection method provided in this application embodiment. Figure 1 This method can be executed on a worker node. The worker node includes a container, a first container network interface (CNI) plugin, and a DPU network interface card including a virtual switch. It is particularly important to emphasize that the worker node also includes a second CNI plugin, the function of which will be described in detail in the following method steps:

[0060] The DPU-based network path detection method mainly includes the following steps S201~S203:

[0061] S201. When the container group is running, the container group information and the corresponding virtual function (VF) network interface information are sent to the second CNI plugin through the first CNI plugin.

[0062] The first CNI plugin is the ovn-kubernetes CNI plugin, which is responsible for completing the standard functions of container networking when a container group pod is created, such as adding VF to the namespace of the container group pod network as its network interface, and allocating container network addresses, etc.

[0063] Container group information includes the address of the container group's Virtual Network Interface Card (VNIC).

[0064] The second CNI plugin is the Peerless CNI plugin, responsible for configuring the Peerless Echo protocol for the container network interface of the container group pods after successful container group network configuration. The Peerless Echo protocol (Peerless BFD, Peerless Echo) does not require both communicating parties to have negotiation Echo capabilities; one end configures BFD detection, while the other end does not require BFD functionality. Devices with Peerless Echo enabled send special BFD messages. The source and destination IPs in the IP header are both the local device's IP address. The local identifier (My Discriminator) and the peer identifier (Your Discriminator) in the BFD protocol message are the same. Upon receiving this, the peer immediately loops back to the local end to determine if the link is functioning correctly. The Peerless Echo function has strong adaptability to low-end devices.

[0065] like Figure 3A , Figure 3AThe worker node shown includes a container group (Pod), a daemon (Kubelet), an agent CNI plugin (Multus CNI), a first CNI plugin (ovn-kubernetes CNI), a second CNI plugin (BFD CNI), a third CNI plugin (SRIOV device plugin, SRIOV CNI), a VF list, and a PF network interface.

[0066] Multus CNI enables multiple CNIs to participate in the creation of a container network for a single pod, distributing different network configuration tasks to ovn-kubernetes CNI, BFD CNI, and SRIOV CNI. SRIOV CNI is responsible for selecting a VF interface and providing VF interface information to ovn-kubernetes CNI when a container group is scheduled to a worker node. The PF interface is a network adapter supporting PCI Express (PCIe) functionality for a single root I / O virtualization (SR-IOV) interface. The worker node has a DPU network card installed; the DPU SOC includes a VFR list and PFR interface, as well as a client controller (ovsdbClient controller) and a virtual switch (ovs).

[0067] Combination Figure 3A When a container group Pod is running, the ovn-kubernetes CNI plugin sends the container group information and the corresponding VF network interface information to the BFD CNI plugin.

[0068] In some embodiments, prior to step S201, when the container group starts up, a single-arm echo protocol is configured for the VF interface corresponding to the container group via a second CNI plugin. By deploying the second CNI plugin on the worker node, the single-arm echo protocol is automatically configured to facilitate dynamic detection of network path connectivity.

[0069] S202. Configure single-arm echo messages according to container group information through the second CNI plugin, and send single-arm echo messages through the VF network interface indicated by the VF network interface information. The destination address of the single-arm echo message is the same as the source address.

[0070] In some embodiments, since the container group information includes the container group's VNIC address, when executing step S202, the destination address and source address of the single-arm echo message are configured to be the container group's VNIC address through the second CNI plugin, and the single-arm echo message is sent through the network port indicated by the network port information.

[0071] Specifically, the second CNI sets the destination address (dst:vnic ip) and source address (src:vnic ip) of the single-arm echo message based on the VNIC address, and continuously sends the single-arm echo message on the VF interface indicated by the VF interface information. For example... Figure 3B As shown, the container group Pod sends a single-arm echo message with a destination address dst:vnic ip and a source address src:vnic ip through the VF network interface to be transmitted to the corresponding VFR through the network path, and then flows to the virtual switch ovs.

[0072] S203. If the second CNI plugin detects a response message for a single-arm echo message, determine that the network path corresponding to the VF port is connected.

[0073] The network path corresponding to the VF port refers to the network path from the VF port to the VFR port.

[0074] If the VF port and VFR port are connected, the virtual switch OVS on the DPU SOC can send a response message back to the container group Pod via the VFR port based on the destination address of the single-arm echo message (i.e., the VNIC address of the container group Pod). When the second CNI plugin receives the response message returned by the virtual switch via VFR, it can determine that the VF port and VFR port are connected, that is, the network path between the container group and the virtual switch on the DPU SOC is connected.

[0075] In some embodiments, after executing step S202, if the working node NODE sends a response message to the VFR interface corresponding to the VF interface through the virtual switch OVS, and the source address (src:vnic ip) and destination address (dst:vnicip) of the response message are the same and both are the VNIC address of the container group, then the second CNI plugin may detect the response message of the single-arm echo message and execute step S203.

[0076] like Figure 3B As shown, the virtual switch OVS responds to the single-arm echo message by sending a response message with the source address src:vnic ip and the destination address dst:vnic ip through the corresponding VFR network port for detection by the second CNI plugin.

[0077] In other embodiments, if the second CNI plugin does not detect a response message for a single-arm echo message, the network path corresponding to the VF interface is marked as faulty. Specifically, the container group Pod is marked with an identifier indicating that the corresponding network path is faulty and disconnected.

[0078] Understandably, if there is no connection between the VF port and the VFR port, it's either because the link in the VF port to VFR port direction is broken, and the virtual switch on the DPU SOC cannot receive the single-arm echo message, or because the link in the VFR port to VF port direction is broken, and the second CNI plugin cannot receive the response message returned by the virtual switch through VFR. Both of these situations will cause the second CNI plugin to not receive the response message. Therefore, when the second CNI plugin does not receive the response message returned by the virtual switch through VFR, it is determined that the network path between the VF port and VFR is broken, and the container group Pod is marked for subsequent processing.

[0079] The above embodiments are based on single-arm message regression technology, which can detect network path connectivity with low power consumption and in a timely manner, thereby quickly detecting faults, realizing network path reactivation, and enhancing the availability of container network interfaces. In some embodiments, the creation of container groups and network configuration processes are also included before the execution of the above step S201, such as... Figure 4 As shown, Figure 4 A flowchart illustrating a DPU-based network path liveness detection method provided in this application embodiment. Figure 2 The method includes the following steps S401~S403:

[0080] S401. When a container group is scheduled to a worker node, select an available Virtual Function (VF) interface for the container group and request the control node to change the container resources so that the control node can create an incremental entry for the Logical Switch Port (LSP) carrying the VF interface information in the northbound database.

[0081] Combination Figure 3C When a container group Pod is scheduled to a worker node, the worker node first calls SRIOV CNI through the daemon process Kubelet to select an available Virtual Functions (VF) interface for the container group Pod from the VF list. SRIOV CNI then transmits the VF interface information to ovn-kubernetes CNI. Next, ovn-kubernetes CNI sends a request to the Kubernetes API Server, the resource interface server of the control node Master, to request that the VF interface information be written to the container namespace of the distributed key-value store etcd, thus completing the container resource change and VF interface configuration.

[0082] On the Master control node side, such as Figure 3CThe control node Master shown includes: Kubernetes API Server (resource interface server), etcd (distributed key-value store), ovn-kubernetescontroller (resource controller), and ovn nbdb (northbound database).

[0083] In response to the request, the Kubernetes API Server writes the VF interface information to the container namespace pod info in the distributed key-value store etcd. The resource controller ovn-kubernetes controller listens for this container resource change event and, in response, creates an incremental LSP entry for the container pod's logical switch port in the northbound database ovn nbdb. It is important to note that this incremental LSP entry carries the VF interface information (VFinfo). Then, the northbound database ovn nbdb sends a resource synchronization request to the client controller ovsdbClientcontroller on the worker node NODE side. This resource synchronization request includes the incremental LSP entry.

[0084] S402, listens to the northbound database through the client controller on the DPU network card.

[0085] The client controller ovsdbClient controller on the DPU network card is used to listen for changes to LSP resources in the northbound database ovn nbdb.

[0086] In some embodiments, the client controller requests all LSP entries from the northbound database; upon receiving the full LSP entries returned by the northbound database, the full LSP entries are stored in the local cache; and the system waits for the northbound database to send a resource synchronization request. Thus, during subsequent monitoring, only the changed incremental LSP entries are retrieved, and the full LSP entries are updated accordingly.

[0087] S403. After the client controller listens to the resource synchronization request sent by the northbound database, the resource synchronization request includes LSP incremental entries. In response to the resource synchronization request, the client controller adds the virtual function representative port (VFR) corresponding to the VF network interface information to the virtual switch.

[0088] like Figure 3CAs shown, suppose the client controller ovsdb sends a resource synchronization request to the northbound database ovn nbdb after changing the LSP resources. This resource synchronization request carries the information of the VF interface previously selected by the daemon process kubelet. In response to this resource synchronization request, the corresponding VFR is added to the virtual switch ovs based on the VF interface information. The VF interface is connected to the VFR on the DPU SOC, thereby establishing a network path for information transmission between the container group pod and the virtual switch ovs.

[0089] In some embodiments, the ovsdbClient controller, in response to the resource synchronization request, first caches the LSP incremental entries, specifically synchronizing the LSP incremental entries to the local cache to update the original full LSP entries in the local cache; then, it adds the VFR corresponding to the VF port information to the virtual switch ovs. In the above embodiments, when a container group is scheduled to a worker node, an available virtual function (VF) port is selected for the container group, and the control node is requested to change the container resources so that the control node can create a logical switch port LSP incremental entry carrying the VF port information in the northbound database; the client controller on the DPU network card listens to the northbound database; after the client controller listens to the resource synchronization request sent by the northbound database, the resource synchronization request includes the LSP incremental entries, and in response to the resource synchronization request, the client controller adds the virtual function representative port (VFR) corresponding to the VF port information to the virtual switch. Thus, in this embodiment, the client controller on the DPU network card listens to the northbound database instead of listening to the distributed key-value store etcd through the resource controller. This avoids the cumbersome steps of configuring certificates and keys and mitigates the corresponding security risks, making network configuration simpler and more secure. In addition, by responding to resource synchronization requests actively sent by the northbound database through the client controller on the DPU network card, incremental LSP entries are cached, avoiding frequent access to the remote etcd resource interface server, thereby reducing the load on the control node and improving the cluster response speed.

[0090] like Figure 5 As shown, Figure 5 A working node is provided in an embodiment of this application. The working node includes a container group, a first CNI plugin, and a DPU network interface card including a virtual switch. The working node also includes a second CNI plugin, wherein:

[0091] The first CNI plugin 501 is used to send container group information and corresponding virtual function (VF) interface information to the second CNI plugin during container runtime.

[0092] The second CNI plugin 502 is used to configure single-arm echo messages according to container group information and send single-arm echo messages through the VF network interface indicated by the VF network interface information. The destination address of the single-arm echo message is the same as the source address. When a response message of the single-arm echo message is detected, the network path corresponding to the network interface is determined to be connected.

[0093] As an optional implementation of this application, the second CNI plugin 502 is also used to: mark the network path corresponding to the VF port as faulty when no response message of the single-arm echo message is detected.

[0094] As an optional implementation of this application, the container group information includes the virtual network interface (VNIC) address of the container group; the second CNI plugin 502 is specifically used to: configure the destination address and source address of the single-arm echo message to be the VNIC address of the container group; and send the single-arm echo message through the VF port indicated by the VF port information.

[0095] As an optional implementation of this application, the second CNI plugin 502 is also used to: configure the single-arm echo protocol for the VF port corresponding to the container group when the container group starts up.

[0096] As an optional implementation of this application, the working node further includes a virtual switch, which is used to send a response message to the VFR port corresponding to the VF port. The source address and destination address of the response message are the same, which is the virtual network interface (VNIC) address of the container group.

[0097] As an optional implementation of this application, the first CNI plugin 501 is further configured to: when a container group is scheduled to a worker node, select a VF network interface for the container group and request the control node to change the container resources so that the control node can create a logical switch port LSP incremental entry carrying VF network interface information in the northbound database; the worker node also includes: a client controller on the DPU network card, used to listen to the northbound database; after the client controller listens to the resource synchronization request sent by the northbound database, the resource synchronization request includes the LSP incremental entry, and in response to the resource synchronization request, add the virtual function representative port (VFR) corresponding to the VF network interface information to the virtual switch.

[0098] It should be noted that the structure of the control node provided in the embodiments of this application can be referred to Figure 3A , 3B The components shown in 3C are not described in detail here.

[0099] For specific limitations regarding the control node, please refer to the limitations of the DPU-based network path detection method mentioned above, which will not be repeated here. Each module in the control node can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0100] In one embodiment, this application provides an electronic device, which may be a terminal, and its internal structure diagram may be as follows. Figure 6 As shown, the electronic device includes a processor, memory, communication interface, display screen, and input device connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a stuttering detection method. The display screen can be an LCD screen or an e-ink screen. The input device can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the device's casing, or an external keyboard, touchpad, or mouse.

[0101] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0102] This application provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the continuous prefix fine-tuning method for the large language model described in the above-described method embodiments, and achieves the same technical effect.

[0103] The computer-readable storage medium can be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0104] This application provides a computer program product that stores a computer program. When the computer program is executed by a processor, it implements each process of the intelligent monitoring method for structural safety during multi-stage construction of buildings in the above-described method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0105] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code.

[0106] It should be understood, in the several embodiments provided in this application, that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0107] In this application, the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0108] In this application, memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0109] In this application, computer-readable media includes both permanent and non-permanent, removable and non-removable storage media. Storage media can implement information storage using any method or technology; the information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient media, such as modulated data signals and carrier waves.

[0110] 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. Unless otherwise specified, 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 the element.

[0111] The above are merely specific embodiments of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to these embodiments, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A DPU-based network path alive detection method, applied to a worker node, the worker node comprising a container group, a first CNI plugin, and a DPU network card comprising a virtual switch, characterized in that, The working node also includes a second CNI plug-in; the method includes: During the running of the container group, sending container group information and corresponding virtual function VF network port information to the second CNI plug-in through the first CNI plug-in; Configuring a one-arm echo packet according to the container group information through the second CNI plug-in, and sending the one-arm echo packet through the VF network port indicated by the VF network port information, the destination address and the source address of the one-arm echo packet being the same; In the case where the second CNI plug-in detects a response packet of the one-arm echo packet, determining that the network path corresponding to the VF network port is connected.

2. The method of claim 1, wherein, After the step of configuring a one-arm echo packet according to the container group information through the second CNI plug-in, and sending the one-arm echo packet through the VF network port indicated by the VF network port information, the method further includes: In the case where the second CNI plug-in does not detect a response packet of the one-arm echo packet, marking the network path corresponding to the VF network port as faulty.

3. The method of claim 1, wherein, The container group information includes a virtual network interface VNIC address of the container group; The step of configuring a one-arm echo packet according to the container group information through the second CNI plug-in, and sending the one-arm echo packet through the VF network port indicated by the VF network port information includes: Through the second CNI plug-in, configuring the destination address and the source address of the one-arm echo packet to be the VNIC address of the container group; Sending the one-arm echo packet through the VF network port indicated by the VF network port information.

4. The method of claim 1, wherein, Before the step of, during the running of the container group, sending container group information and corresponding virtual function VF network port information to the second CNI plug-in through the first CNI plug-in, the method further includes: When the container group is started, configuring a one-arm echo protocol for the VF network port corresponding to the container group through the second CNI plug-in.

5. The method of claim 1, wherein, After the step of configuring a one-arm echo packet according to the container group information through the second CNI plug-in, and sending the one-arm echo packet through the VF network port indicated by the VF network port information, and in the case where the second CNI plug-in detects a response packet of the one-arm echo packet, determining that the network path corresponding to the VF network port is connected, the method further includes: Sending the response packet to the VFR network port corresponding to the VF network port through the virtual switch, the source address and the destination address of the response packet being the same, and being a virtual network interface VNIC address of the container group.

6. The method of claim 1, wherein, Before the step of, during the running of the container group, sending container group information and corresponding virtual function VF network port information to the second CNI plug-in through the first CNI plug-in, the method further includes: When the container group is scheduled to the working node, selecting a VF network port for the container group, and requesting the control node to change container resources, so as to create a logical switch port LSP incremental entry carrying VF network port information in a northbound database by the control node; Listening to the northbound database through a client controller on the DPU network card; After the client controller listens to the resource synchronization request sent by the northbound database, the resource synchronization request includes the LSP incremental entry, and in response to the resource synchronization request, a virtual function representative port VFR corresponding to the VF network port information is added to a virtual switch by the client controller.

7. A worker node comprising a container group, a first CNI plugin, and a DPU network card comprising a virtual switch: characterized in that, The worker node further includes a second CNI plug-in, wherein: The first CNI plug-in is configured to send container group information and corresponding virtual function VF network port information to the second CNI plug-in when the container group is running; The second CNI plug-in is configured to configure a one-arm echo packet according to the container group information, and send the one-arm echo packet through a VF network port indicated by the VF network port information, the one-arm echo packet having the same destination address and source address; and in a case where a response packet of the one-arm echo packet is detected, determine that a network path corresponding to the VF network port is connected.

8. An electronic device, comprising: Comprise: A processor, a memory, and a computer program stored on the memory and executable on the processor, the computer program being executed by the processor to implement the DPU-based network path alive detection method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, Comprise: A computer program is stored on the computer readable storage medium, and the computer program is executed by the processor to implement the DPU-based network path alive detection method according to any one of claims 1 to 6.

10. A computer program product, characterised in that, Comprise: The computer program product comprises a computer program, which, when executed on a computer, causes the computer to implement the DPU-based network path alive detection method according to any one of claims 1 to 6.

Images