Dpu-based k8s cluster multi-network card service discovery method and device and storage medium

Abstract

The application provides a DPU-based K8S cluster multi-network card service discovery method and device and a storage medium. The service discovery method comprises the following steps: obtaining a service call request and multi-network card information of a pod, the multi-network card comprising a first network card for connecting an internal network of the K8S cluster and a second network card for connecting an external network, and the multi-network card information comprising network card IP address information; determining virtual IP address information corresponding to the second network card, generating a forwarding rule based on a preset service strategy, network card IP address information corresponding to the second network card and the virtual IP address information; determining a target network card of a target pod based on the forwarding rule and a request address contained in the service call request, and forwarding the request based on the determined target network card. The method improves the network performance and efficiency of service discovery in the multi-network card scenario.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a method, apparatus and storage medium for discovering multi-NIC services in a Kubernetes cluster based on a DPU. Background Technology

[0002] Kubernetes (K8S) is an open-source container orchestration platform for automatically deploying, scaling, and managing containerized applications. It provides a scalable, highly available framework for managing containers across multiple hosts and implementing application lifecycle management, resource scheduling, service discovery, and load balancing. In Kubernetes, applications are packaged into containers and deployed and managed as Pods. Each Pod can contain one or more closely related containers that share network and storage resources. Kubernetes uses a declarative API and controller pattern to automatically manage the application's lifecycle by describing its desired state. Kubernetes' network model assumes that each Pod has a unique IP address and that Pods can communicate directly without NAT. This flattened network model simplifies application development and deployment but also places higher demands on the underlying network.

[0003] In traditional Kubernetes (K8S) clusters, Pods typically have only one network interface card (NIC), and service discovery and load balancing are achieved using the kube-proxy component via iptables or IPVS rules. However, with the increasing complexity of application architectures and higher network performance requirements, the need to configure multiple NICs for Pods is growing. Therefore, service discovery in multi-NIC scenarios within K8S clusters has become a challenging problem. To address this issue, existing technologies offer several solutions, such as configuring multiple CNI plugins for Pods using Multus-CNI to achieve multi-NIC functionality; others employ technologies like SR-IOV and DPDK, bypassing the kernel protocol stack and directly utilizing hardware offloading to improve network performance. However, these multi-NIC service discovery methods require application modifications or manual configuration of additional service discovery mechanisms, failing to effectively solve the service discovery problem and resulting in low network performance and efficiency. Therefore, improving the network performance and efficiency of service discovery in multi-NIC scenarios is a pressing technical issue that needs to be addressed. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a method, apparatus and storage medium for multi-NIC service discovery in a Kubernetes cluster based on a DPU, in order to eliminate or improve one or more defects existing in the prior art.

[0005] One aspect of the present invention provides a multi-NIC service discovery method for a Kubernetes cluster using a DPU, the service discovery method comprising:

[0006] Obtain service call requests and pod multi-NIC information. The multi-NIC includes a first NIC for connecting to the internal network of the K8S cluster and a second NIC for connecting to the external network. The multi-NIC information includes NIC IP address information.

[0007] Determine the virtual IP address information corresponding to the second network interface card, and generate forwarding rules based on the preset service policy, the network interface card IP address information corresponding to the second network interface card, and the virtual IP address information;

[0008] The target network interface of the target pod is determined based on the forwarding rules and the request address contained in the service call request, and the request is forwarded based on the determined target network interface.

[0009] In some embodiments of the present invention, forwarding rules are generated based on a preset service policy, the network interface card IP address information corresponding to the second network interface card, and the virtual IP address information, including:

[0010] OVS flow table rules are generated based on the preset service policy, the network card IP address information corresponding to the second network card, and the virtual IP address information.

[0011] In some embodiments of the present invention, the target network interface of the target pod is determined based on forwarding rules and the request address contained in the service call request, and request forwarding is performed based on the determined target network interface, including:

[0012] OVS bridges determine the target network interface card corresponding to the requested address using a matching algorithm based on OVS flow table rules.

[0013] Based on the target network interface card's IP address and MAC address information, modify the source IP address and source MAC address in the request data packet to the target IP address and target MAC address;

[0014] The modified request data packet is forwarded to the target network interface card.

[0015] In some embodiments of the present invention, the method further includes:

[0016] Deploy the Multus-CNI plugin and the OVS plugin in the K8S cluster.

[0017] In some embodiments of the present invention, the method further includes:

[0018] Configure multiple network interfaces for the pod.

[0019] In some embodiments of the present invention, the method further includes: obtaining a pod deployment request, and updating the OVS flow table rules based on the obtained pod deployment request; and / or,

[0020] Obtain the response data packet and forward the response data packet based on the OVS bridge.

[0021] In some embodiments of the present invention, the forwarding rules include: the mapping relationship between network card IP address information and virtual IP address information, protocol type, and operation content.

[0022] According to another aspect of the present invention, a DPU-based K8S cluster multi-NIC service discovery device is also disclosed. The device includes a processor, a memory, and a computer program stored in the memory. The processor is used to execute the computer program. When the computer program is executed, the device implements the steps of the method as described in any of the above embodiments.

[0023] According to another aspect of the present invention, a computer-readable storage medium is also disclosed, on which a computer program is stored, which, when executed by a processor, implements the steps of the method as described in any of the above embodiments.

[0024] According to another aspect of the present invention, a computer program product is also disclosed, comprising a computer program that, when executed by a processor, implements the steps of the method as described in any of the above embodiments.

[0025] The DPU-based Kubernetes cluster multi-NIC service discovery method disclosed in the above embodiments of this application obtains multi-NIC information of pods in real time, automatically generates forwarding rules for pods based on preset service policies, and forwards service call requests to the target NIC based on the forwarding rules. This service discovery method supports multi-NIC scenarios, does not require modification of the application, simplifies application development and deployment, and not only improves the network performance of service discovery in multi-NIC scenarios, but also improves the efficiency of service discovery in multi-NIC scenarios.

[0026] Furthermore, this application implements Kubernetes multi-NIC service discovery based on OVS flow table rules. That is, by utilizing the OVS flow table mechanism, it achieves transparent service discovery for Pods with multiple NICs through flexible matching rules and processing actions. Compared with Kubernetes' native kube-proxy, the DPU-based Kubernetes cluster multi-NIC service discovery method in this application not only supports multi-NIC scenarios but also provides more granular traffic control and forwarding strategies. By decoupling service discovery from OVS flow tables, the implementation of the control plane and data plane is simplified, and the scalability of the solution is improved.

[0027] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the description, or may be learned by practice of the invention. The objects and other advantages of the invention can be realized and obtained by means of the structures specifically pointed out in the specification and drawings.

[0028] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description

[0029] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, are not intended to limit the scope of the invention. The components in the drawings are not drawn to scale but are merely illustrative of the principles of the invention. For ease of illustration and description of certain parts of the invention, corresponding portions in the drawings may be enlarged, i.e., may appear larger relative to other components in an exemplary device actually manufactured according to the invention. In the drawings:

[0030] Figure 1 This is a flowchart illustrating a DPU-based Kubernetes cluster multi-NIC service discovery method according to an embodiment of this application.

[0031] Figure 2 This is a schematic diagram of the architecture of a DPU-based Kubernetes cluster multi-NIC service discovery device according to an embodiment of this application.

[0032] Figure 3 This is a schematic diagram of the architecture of a DPU-based K8S cluster multi-NIC service discovery device according to another embodiment of this application.

[0033] Figure 4 This is a schematic diagram of an SRIOV extension according to an embodiment of this application. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.

[0035] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.

[0036] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0037] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection with an intermediary, and can refer not only to a wired connection, but also to a wireless connection. The specific meaning can be changed based on the actual application scenario.

[0038] To better understand this invention, the following explanations of terms related to the technical solutions are provided:

[0039] Open vSwitch (OVS) is an open-source virtual switch that provides a high-performance, programmable network forwarding and control plane. It supports multiple network protocols and standards, such as OpenFlow, OVSDB, and VXLAN, and allows for flexible construction and management of virtual networks. The core components of OVS include ovs-vswitchd (data plane) and ovsdb-server (configuration database). ovs-vswitchd handles packet forwarding and processing, supporting flexible flow table matching and manipulation; ovsdb-server stores OVS configuration information and provides a programmable interface for managing and querying the status of virtual switches. OVS is widely used in cloud computing and virtualization environments, and is particularly suitable for building SDN (Software-Defined Networking) and NFV (Network Functions Virtualization) solutions. When used in conjunction with Kubernetes, it can enable highly customizable and flexible container networks.

[0040] The controller plays a crucial role in Software-Defined Networking (SDN) and cloud-native environments. It is a centralized or distributed entity responsible for managing and controlling network behavior. The controller communicates with the data plane (such as OVS) through southbound interfaces (e.g., OpenFlow), issuing forwarding rules and flow tables to enable programmable and dynamic control of the network. In Kubernetes environments, network controllers typically integrate with the Kubernetes API Server, listening for changes in Pods and Services and adjusting network configurations accordingly. The controller can automatically assign IP addresses to newly created Pods, configure the network, and generate flow tables based on predefined policies and algorithms, achieving automated network management. The introduction of the controller improves the network's flexibility, scalability, and intelligence. It decouples the network's control plane from the data plane, allowing for dynamic configuration and optimization of the network in a software-defined manner, adapting to different application requirements and network topologies.

[0041] The Container Network Interface (CNI) is the standard and specification for Kubernetes network plugins, defining the interface between the container runtime and network plugins. It provides a set of APIs and protocols that allow different network plugins to integrate with the container runtime, enabling network connectivity and management for containers. CNI plugins describe network configuration information, including network type, IP address range, and gateway, through configuration files (such as JSON format). When a Pod is created, Kubernetes calls the CNI plugin to configure its network, assign IP addresses, and connect to the specified network. CNI's design goal is to provide a simple, pluggable, and composable container networking solution; it allows users to select and combine different network plugins, such as Flannel, Calico, Weave, and OVS-CNI, to achieve flexible network configuration.

[0042] Multus-CNI is a CNI plugin for Kubernetes that supports configuring multiple network interfaces in a Pod. As a "meta-plugin," it coordinates and manages other CNI plugins to enable multiple network connections for a Pod. In the standard Kubernetes network model, each Pod can only connect to one network. However, in some scenarios, a Pod may need to connect to multiple networks simultaneously, such as the management network and the data network. Multus-CNI achieves this by creating multiple network interfaces in the Pod, each connecting to a different network. When using Multus-CNI, users can declare the Pod's multiple network requirements using Kubernetes annotations or custom resource declarations (CRDs). Based on these declarations, Multus-CNI calls the underlying CNI plugin to configure the corresponding network interfaces for the Pod. Furthermore, it provides flexible configuration options, such as network priority and bandwidth limits, to meet different application needs.

[0043] In traditional Kubernetes clusters, Pods typically have only one network interface card (NIC), and service discovery is achieved through the kube-proxy component using iptables or IPVS rules. However, as application architectures become more complex and network performance requirements increase, some Pods are configured with multiple NICs. When a Pod has multiple NICs, the conventional service discovery mechanism based on the kube-proxy component fails to function properly, primarily for the following reasons: kube-proxy only recognizes the Pod's default NIC and cannot detect or manage additional NICs; multiple NICs in a Pod usually correspond to different IP addresses and network spaces, while abstractions like Services can only map to the IP address of the default NIC; traffic from different NICs may require differentiated forwarding and load balancing strategies, while kube-proxy rules are relatively simple; forwarding data packets from multiple NICs through kube-proxy incurs additional overhead, impacting network performance. Therefore, in multi-NIC scenarios, the native service discovery function of Kubernetes (K8S) currently has many limitations. Developers typically need to manually configure or modify applications to adapt, significantly increasing operational complexity. This application discloses a DPU-based multi-NIC service discovery method for K8S clusters. Specifically, this application introduces an intelligent controller and OVS flow table mechanism to achieve transparent service discovery for multi-NIC Pods in K8S. Specifically, this multi-NIC service discovery method automatically identifies the multi-NIC information of a Pod and generates an OVS flow table based on a preset service policy; dynamically senses changes in the Pod's lifecycle and adjusts the flow table rules in real time; distributes the generated flow table rules to the OVS bridge to achieve Layer 2 and Layer 3 forwarding and load balancing; and provides flexible flow table matching conditions and processing actions, supporting differentiated service discovery strategies.

[0044] This application's multi-NIC service discovery method solves the problem of multi-NIC service discovery through Software-Defined Networking (SDN) without changing the Kubernetes cluster and applications, providing a novel approach and architecture. Compared to kube-proxy's rule-based forwarding, OVS flow table-based forwarding offers advantages such as higher performance, stronger functionality, and greater flexibility, making it particularly suitable for high-performance network applications. Furthermore, this invention fully leverages the controller's global perspective and intelligent scheduling capabilities, simplifying multi-NIC management and maintenance.

[0045] In the following description, embodiments of the invention will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0046] Figure 1 This is a flowchart illustrating a DPU-based Kubernetes cluster multi-NIC service discovery method according to an embodiment of this application. Figure 1 As shown, the DPU-based K8S cluster multi-NIC service discovery method includes at least steps S10 to S30.

[0047] Step S10: Obtain the service call request and the pod's multi-NIC information. The multi-NIC includes a first NIC for connecting to the internal network of the K8S cluster and a second NIC for connecting to the external network. The multi-NIC information includes NIC IP address information.

[0048] In this step, the multi-NIC information of the pod is obtained in real time. The first NIC can be the default NIC used to connect to the internal network of the Kubernetes cluster, and the second NIC can be an additional NIC used to connect to the external network. In the traditional single-NIC scenario, since it only has a default NIC, when publishing web services and implementing load balancing through the Kubernetes Service abstraction, a Service named web-service is typically created and mapped to the default NIC IP of Pod 1. However, in a multi-NIC scenario, since there is an additional NIC besides the default one, the following problems arise: the Service IP belongs to the internal network of the cluster, and external clients cannot directly access the web-service; the additional NIC IP of the Pod is not discovered and utilized, wasting network resources.

[0049] The multi-NIC information of a pod can be obtained through the intelligent controller. As a core component, the intelligent controller is responsible for listening to the Kubernetes API Server and obtaining the pod's multi-NIC information in real time. In addition, the intelligent controller can also monitor pod change events in real time and dynamically adjust the OVS flow table rules mentioned in subsequent steps based on these changes to ensure the real-time performance and accuracy of service discovery. In this application, the introduction of the intelligent controller greatly simplifies the operation and maintenance management in a multi-NIC environment and improves the system's automation level.

[0050] Step S20: Determine the virtual IP address information corresponding to the second network card, and generate forwarding rules based on the preset service policy, the network card IP address information corresponding to the second network card, and the virtual IP address information.

[0051] In this step, the intelligent controller maintains a service discovery policy engine. Based on a preset service policy, it generates corresponding forwarding rules for each Pod's Calico and OVS network interfaces. These forwarding rules can, for example, include the mapping relationship between network interface IP address information and virtual IP address information, the protocol type, and the operation content. The operation content can, for example, include modifying the destination MAC address or port forwarding. The mapping relationship between network interface IP address information and virtual IP address information, and the protocol type, serve as matching conditions to match the source IP address in the request data packet with the destination IP address. In this embodiment, the source IP address corresponds to the virtual IP address information, while the destination IP address is the network interface IP address information that matches the virtual IP address information.

[0052] Understandably, the intelligent controller listens to changes in resources such as Pods through the K8S API Server, monitors the lifecycle of Pods and information about multiple network interfaces in real time, and dynamically adjusts forwarding rules when Pods change (such as creation, deletion, migration, etc.), which can ensure the real-time and accuracy of service discovery.

[0053] In one embodiment, forwarding rules are generated based on a preset service policy, the network interface card (NIC) IP address information corresponding to the second NIC, and the virtual IP address information. This includes generating OVS flow table rules based on the preset service policy, the NIC IP address information corresponding to the second NIC, and the virtual IP address information. In this embodiment, the forwarding rules are specifically OVS flow table rules. These flow table rules may include matching conditions (such as source IP, destination IP, protocol type, etc.) and operation content (such as modifying the destination MAC address, port forwarding, etc.). Specifically, when the intelligent controller detects a change in a Pod (such as creation, deletion, etc.), it automatically generates the corresponding OVS flow table according to the preset service discovery rules (such as virtual IP mapping) to determine the target NIC corresponding to the request data packet based on the OVS flow table. Since the intelligent controller automatically generates the corresponding OVS flow table rules for the Pod according to the preset service discovery policy, no manual intervention is required, thereby improving the automation level of service discovery and thus improving the efficiency of service discovery.

[0054] Step S30: Determine the target network interface of the target pod based on the forwarding rules and the request address contained in the service call request, and perform request forwarding based on the determined target network interface.

[0055] This step can be implemented using an OVS bridge. The OVS bridge connects the Pod's Calico network interface (eth0) and the OVS network interface (net1), and is responsible for forwarding and processing traffic between them. In the previous step, the intelligent controller distributed the generated OVS flow table to the OVS bridge in the cluster via an OVS management protocol (such as OpenFlow), enabling the OVS bridge to match and process traffic according to the OVS flow table rules distributed by the intelligent controller. For example, when an external request accesses a service through the Service's VIP (virtual IP), the request packet is captured by the OVS bridge. The OVS bridge modifies the destination IP and MAC in the request packet according to the matching flow table rules and forwards it to the corresponding network interface of the backend Pod. Furthermore, after the Pod processes the request, the response packet is returned along the same path and then forwarded to the client by the OVS bridge, achieving transparent service discovery.

[0056] In this step, the OVS bridge applies OVS flow table rules to process packets that match the conditions, enabling service discovery and load balancing between multiple network interfaces of a Pod and between a Pod and external systems. The service discovery mechanism based on the controller and OVS flow tables in the above embodiment has advantages such as flexibility, efficiency, and scalability. The intelligent controller has a global understanding of the network state and can dynamically adjust the flow table according to the load, providing more intelligent traffic scheduling. The OVS bridge, when forwarding packets, only needs to perform a simple table lookup without involving complex logic, resulting in higher performance. At the same time, flow table rules can be flexibly customized, supporting richer matching conditions and processing actions to meet diverse service discovery needs.

[0057] In one embodiment, the target network interface card (NIC) of the target pod is determined based on forwarding rules and the request address contained in the service call request. Request forwarding is then performed based on the determined target NIC. Specifically, this may include: the OVS bridge determining the target NIC corresponding to the request address using a matching algorithm based on OVS flow table rules; modifying the source IP address and source MAC address in the request data packet to the target IP address and target MAC address based on the NIC's IP address and MAC address information; and forwarding the modified request data packet to the target NIC.

[0058] Furthermore, to achieve multi-NIC service discovery as described in this application, the Multus-CNI plugin and OVS plugin can be deployed in the Kubernetes cluster, and / or multiple NICs can be configured for pods. Specifically, the Kubernetes cluster can integrate multiple network plugins through the CNI framework, including Device Plugin Manager, Multus-CNI, Calico-CNI, OVS-CNI, and SRIOV-CNI. Multus-CNI, as the main plugin, is responsible for managing and coordinating other auxiliary plugins to achieve multi-NIC configuration for pods. Calico-CNI provides ordinary Layer 3 network connectivity, OVS-CNI provides OVS-based overlay networking, and SRIOV-CNI provides high-performance direct-connect networking. In this embodiment, SRIOV technology is integrated, providing a high-performance direct-connect network option.

[0059] When declaring and configuring multiple network interfaces for a pod, the cluster administrator can use Kubernetes network attachment mechanisms (such as annotations) to declare multiple network interfaces for the pod. These multiple network interfaces can simultaneously include Calico, OVS, and SRIOV types; for example... Figure 3 As shown, Multus-CNI configures the corresponding network interfaces for the Pod based on the declaration, including the Calico network interface (eth0), the OVS network interface (net1), and the SRIOV network interface (net2). Furthermore, the Pod can connect to multiple networks simultaneously, enabling flexible multi-network communication.

[0060] In the above embodiments, the OVS flow table mechanism is introduced, which achieves efficient data plane forwarding through flexible matching rules and forwarding actions. Compared with the iptables mode of kube-proxy, the OVS flow table provides better forwarding performance and scalability. By dynamically generating and updating flow table rules through the intelligent controller, the workload of manual configuration is reduced and the efficiency of service discovery is improved.

[0061] In one specific embodiment, assume a multi-tiered web application is deployed in a Kubernetes cluster, where the web service is implemented through Pod 1 and the database service is implemented through Pod 2; to improve security and network performance, both Pod 1 and Pod 2 are configured with two network interface cards (NICs), such as... Figure 2 As shown: The default network interface eth0 connects to the internal network of the Kubernetes cluster and is used to communicate with other Pods, with IP addresses 10.244.0.10 and 10.244.0.20 respectively; the additional network interface eth1 connects to the external network and is used to communicate with clients or other external services, with IP addresses 192.168.1.10 and 192.168.1.20 respectively. When publishing web services through the Kubernetes Service abstraction, in order to achieve load balancing and ensure that the additional network interface is discovered and utilized, Multus-CNI and OVS plugins are deployed in the Kubernetes cluster, and a smart controller is deployed to listen for changes in Pods in Kubernetes; the smart controller detects Pod 1 and Pod 2. After creation of 2, the following OVS flow table rules are automatically generated according to the preset service discovery policy: #Web service flow table table=0,priority=1000,in_port=eth1,ip_dst=192.168.1.100,actions=mod_dl_dst:Pod1_MAC,mod_nw_dst:192.168.1.10,output:Pod1_PORT #Database service flow table table=0,priority=1000,in_port=eth1,ip_dst=192.168.1.200,actions=mod_dl_dst:Pod2_MAC,mod_nw_dst:192.168.1.20,output:Pod2_PORT; The intelligent controller then distributes the above flow table rules to the OVS bridge. When an external client accesses the virtual IP 192.168.1.100, the request packet will be matched by OVS to the Web service flow table. Then, the destination IP and MAC address in the request packet will be modified to the values ​​corresponding to eth1 of Pod 1, and finally forwarded to Pod 1 for processing. In addition, after Pod 1 finishes processing the request, the response packet is returned along the same path and then forwarded to the client by the OVS bridge.

[0062] In another embodiment, the DPU-based Kubernetes cluster multi-NIC service discovery method further includes the following steps: obtaining a pod deployment request and updating the OVS flow table rules based on the obtained pod deployment request. In this embodiment, when a pod changes, the OVS flow table rules are dynamically adjusted to ensure the real-time performance and accuracy of service discovery; the intelligent controller dynamically generates and updates the OVS flow table rules, reducing the workload of manual configuration and debugging; and the integration and collaboration of multiple CNI plugins provide a consistent network configuration and management interface, simplifying the operational complexity in multi-network environments. The above embodiments are transparent to existing Kubernetes architectures and applications, requiring no modification to application code, thus reducing migration and usage costs.

[0063] In addition to dynamically updating OVS flow tables, the intelligent controller can also distribute requests across multiple backend Pods based on load balancing strategies (such as Round-Robin and Least-Connection), enabling horizontal scaling of services. As described above, the intelligent controller achieves service discovery and load balancing by distributing generated flow table rules to the OVS bridge; and through flexible flow table matching conditions and processing actions, it supports various service discovery and load balancing strategies, improving the scalability of the solution.

[0064] Accordingly, the present invention also provides a DPU-based K8S cluster multi-NIC service discovery device, the device including a processor, a memory and a computer program stored in the memory, the processor being used to execute the computer program, and when the computer program is executed, the device implementing the steps of the method as described in any of the above embodiments.

[0065] The aforementioned multi-NIC service discovery device reserves an expansion interface for integrating high-performance network technologies (such as SRIOV) to meet scenarios with higher network performance requirements. An SRIOV expansion diagram is shown below. Figure 4 As shown. Furthermore, by adding dedicated CNI plugins (such as SRIOV-CNI) and corresponding device plugins, this device can integrate high-performance network cards such as SRIOV into the solution. Additionally, the intelligent controller can monitor information from the high-performance network cards and adjust the OVS flow table accordingly, forwarding service requests to the high-performance network cards.

[0066] As can be seen from the above embodiments, the DPU-based Kubernetes cluster multi-NIC service discovery method and apparatus of this application realizes the collaboration and integration of multiple CNI plugins. That is, it integrates multiple network plugins through the CNI framework, including Calico-CNI, OVS-CNI, and SRIOV-CNI, thereby providing rich network connection options to meet the network needs of different scenarios. Multus-CNI is used as the main plugin to manage and coordinate other auxiliary plugins, realizing the multi-NIC configuration of Pods. Different types of NICs can be connected to Pods simultaneously, meeting the network performance and flexibility requirements of different applications. The collaboration and integration of multiple CNI plugins expands the network capabilities of Kubernetes and improves the applicability of the solution.

[0067] In addition to the above, the multi-NIC service discovery method and device can also achieve transparent service discovery and load balancing. Specifically, through flexible matching and forwarding of OVS flow table rules, transparent service discovery for Pods with multiple NICs is achieved; external requests access services through the Service's VIP, and the OVS bridge forwards the requests to the backend Pods according to the flow table rules, without modifying the application; the controller supports multiple load balancing strategies, which can distribute requests among multiple backend Pods as needed, realizing horizontal scaling of services; the intelligent controller supports flexible transparent service discovery strategies and load balancing algorithms, which can be customized and extended according to business needs; the decoupling design of core components, such as the decoupling of the intelligent controller and OVS flow tables, improves the scalability and maintainability of the solution.

[0068] Furthermore, the multi-NIC service discovery method disclosed in this application retains the native abstract concepts of Kubernetes such as Service and Endpoint, allowing existing applications to migrate smoothly without code modification, and upper-layer applications do not need to be aware of changes in the underlying network implementation; the controller integrates with the Kubernetes API Server, listening to and managing Pod lifecycle events through standard API interfaces; the configuration and management of multiple NICs are transparent to applications and do not affect regular network configuration and management processes; it is compatible with native Kubernetes abstractions, ensuring smooth integration and transition of the solution in existing architectures and reducing application migration costs; and through integration with the Kubernetes API Server, the technical solution seamlessly connects with existing management tools and processes, reducing operational learning costs.

[0069] In summary, the DPU-based Kubernetes cluster multi-NIC service discovery method and apparatus of this application achieve transparent service discovery for Kubernetes multi-NIC Pods by introducing a mapping from Virtual IP (VIP) to real IP and utilizing OVS flow tables for request forwarding. In the above embodiments, external clients can directly access internal services through the VIP without complex operations such as NAT; the multi-NIC capabilities of Pods are fully utilized, and traffic from different NICs can be isolated; the service discovery strategy is implemented through flow table rules, which are flexible and configurable, supporting more complex load balancing algorithms; the forwarding function is efficiently completed in the OVS kernel, resulting in better performance; the controller automatically generates and synchronizes flow tables, simplifying operation and maintenance and improving reliability. Therefore, it can be seen that this application cleverly utilizes SDN and OVS technologies to overcome the limitations of Kubernetes service discovery, providing strong support for cloud-native applications in complex network environments, and making the management and use of multi-NIC Pods more intelligent and efficient.

[0070] This invention also provides a computer-readable storage medium and a computer program product having a computer program stored thereon, which, when executed by a processor, performs the steps of the method described in any of the above embodiments. The computer-readable storage medium may be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, register, floppy disk, hard disk, removable storage disk, CD-ROM, or any other form of storage medium known in the art.

[0071] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.

[0072] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0073] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0074] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations of the embodiments of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for discovering services across multiple network interface cards (NICs) in a Kubernetes cluster based on a DPU, characterized in that, The service discovery method includes: Obtain service call requests and pod multi-NIC information. The multi-NIC includes a first NIC for connecting to the internal network of the K8S cluster and a second NIC for connecting to the external network. The multi-NIC information includes NIC IP address information. Determine the virtual IP address information corresponding to the second network interface card (NIC), generate forwarding rules based on the preset service policy, the NIC IP address information corresponding to the second NIC, and the virtual IP address information, and generate OVS flow table rules based on the preset service policy, the NIC IP address information corresponding to the second NIC, and the virtual IP address information; The target network interface card (NIC) of the target pod is determined based on the forwarding rules and the request address contained in the service call request. The request is forwarded based on the determined target NIC. The OVS bridge determines the target NIC corresponding to the request address through a matching algorithm based on the OVS flow table rules. Based on the NIC's IP address and MAC address information, the source IP address and source MAC address in the request data packet are modified to the target IP address and target MAC address. The modified request data packet is then forwarded to the target NIC.

2. The method for multi-NIC service discovery in a Kubernetes cluster based on DPU according to claim 1, characterized in that, The method further includes: Deploy the Multus-CNI plugin and the OVS plugin in the K8S cluster.

3. The method for discovering multi-NIC services in a Kubernetes cluster based on DPU according to claim 1, characterized in that, The method further includes: Configure multiple network interfaces for the pod.

4. The method for discovering multi-NIC services in a Kubernetes cluster based on DPU according to claim 1, characterized in that, The method further includes: obtaining a pod deployment request, and updating the OVS flow table rules based on the obtained pod deployment request; and / or, Obtain the response data packet and forward the response data packet based on the OVS bridge.

5. The DPU-based Kubernetes cluster multi-NIC service discovery method according to claim 1, characterized in that, The forwarding rules include: the mapping relationship between network card IP address information and virtual IP address information, protocol type, and operation content.

6. A DPU-based Kubernetes cluster multi-NIC service discovery device, the device comprising a processor, a memory, and a computer program stored in the memory, characterized in that, The processor is used to execute the computer program, and when the computer program is executed, the device implements the steps of the method as described in any one of claims 1 to 5.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 5.

8. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 5.

Images