K8S cluster multi-network card service discovery method and device based on DPU and storage medium

Abstract

The invention provides a DPU-based K8S cluster multi-network card service discovery method and device and a storage medium, and the method comprises the steps: obtaining a service call request and the multi-network card information of a pod, the multi-network card comprises a first network card used for connecting a K8S cluster internal network and a second network card used for connecting an external network, the multi-network card information comprises network card IP address information; virtual IP address information corresponding to the second network card is determined, and a forwarding rule is generated based on a preset service strategy, the network card IP address information corresponding to the second network card and the virtual IP address information; and determining a target network card of the target pod based on the forwarding rule and a request address contained in the service calling request, and carrying out request forwarding based on the determined target network card. According to the method, the network performance and efficiency of service discovery in a multi-network-card scene are improved.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing technology, and in particular to a DPU-based K8S cluster multi-network card service discovery method, device and storage medium. Background Art

[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 in Pods. Each Pod can contain one or more closely related containers that share network and storage resources. Kubernetes uses declarative APIs and controller patterns to automatically manage the lifecycle of an application by describing its desired state. The Kubernetes network model assumes that each Pod has a unique IP address, and that Pods can communicate directly with each other without NAT. This flattened network model simplifies application development and deployment, but also places higher demands on the underlying network.

[0003] In a traditional K8S cluster, a Pod has only one network card by default, and the kube-proxy component can be used to achieve service discovery and load balancing through iptables or IPVS rules. However, with the complexity of application architecture and the improvement of network performance requirements, the demand for configuring multiple network cards for Pod is increasing. Therefore, service discovery in a multi-network card scenario in a K8S cluster has become a thorny problem. In order to solve the service discovery problem in a multi-network card scenario in a K8S cluster, the prior art provides some solutions, such as configuring multiple CNI plug-ins for Pod through Multus-CNI to achieve multi-network card functions; others use SR-IOV, DPDK and other technologies to bypass the kernel protocol stack and directly use hardware offloading methods to improve network performance. The above-mentioned service discovery method in a multi-network card scenario requires modifying the application or manually configuring additional service discovery mechanisms when implementing it, which cannot solve the service discovery problem well, resulting in low network performance and efficiency of service discovery. Therefore, how to improve the network performance and efficiency of service discovery in a multi-network card scenario is a technical problem that needs to be solved urgently. Summary of the invention

[0004] In view of this, an embodiment of the present invention provides a DPU-based K8S cluster multi-network card service discovery method, device and storage medium to eliminate or improve one or more defects existing in the prior art.

[0005] One aspect of the present invention provides a K8S cluster multi-network card service discovery method for DPU, the service discovery method comprising:

[0006] Get the service call request and the multi-NIC information of the pod, where 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 card, and generate a forwarding rule based on the preset service policy, the network card IP address information corresponding to the second network card, and the virtual IP address information;

[0008] The target network card 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 card.

[0009] In some embodiments of the present invention, the forwarding rule is 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, including:

[0010] Generate OVS flow table 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.

[0011] In some embodiments of the present invention, determining a target network card of a target pod based on a forwarding rule and a request address included in a service call request, and forwarding the request based on the determined target network card includes:

[0012] The OVS bridge determines the target NIC corresponding to the request address through a matching algorithm based on the OVS flow table rules;

[0013] Based on the network card IP address information and MAC address information of the target network card, the source IP address and the source MAC address in the request data packet are modified to the target IP address and the target MAC address;

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

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

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

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

[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 rule based on the obtained pod deployment request; and / or,

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

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

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

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

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

[0025] The DPU-based K8S cluster multi-network card service discovery method disclosed in the above embodiments of the present application obtains the multi-network card information of the pod in real time, automatically generates forwarding rules for the pod based on the preset service policy, and forwards the service call request to the target network card based on the forwarding rules. The service discovery method supports multi-network card scenarios without modifying the application program, thus simplifying application development and deployment, which not only improves the network performance of service discovery in multi-network card scenarios, but also improves the efficiency of service discovery in multi-network card scenarios.

[0026] In addition, this application implements Kubernetes multi-NIC service discovery based on OVS flow table rules, that is, utilizing the OVS flow table mechanism to achieve transparent service discovery of Pod multi-NICs through flexible matching rules and processing actions; compared with Kubernetes' native kube-proxy, this application's DPU-based K8S cluster multi-NIC service discovery method not only supports multi-NIC scenarios, but also provides more fine-grained traffic control and forwarding strategies; by decoupling service discovery from the OVS flow table, the implementation of the control plane and data plane is simplified, and the scalability of the solution is improved.

[0027] Additional advantages, purposes, and features of the present invention will be described in part in the following description, and will become apparent to those skilled in the art after studying the following, or may be learned from the practice of the present invention. The purposes and other advantages of the present invention may be achieved and obtained by the structures specifically indicated in the specification and the accompanying drawings.

[0028] Those skilled in the art will appreciate that the objectives and advantages that can be achieved with the present invention are not limited to the above specific description, and the above and other objectives that can be achieved by the present invention will be more clearly understood from the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The drawings described herein are used to provide a further understanding of the present invention, constitute a part of this application, and do not constitute a limitation of the present invention. The components in the drawings are not drawn to scale, but are only for illustrating the principles of the present invention. In order to facilitate the illustration and description of some parts of the present invention, the corresponding parts in the drawings may be enlarged, that is, they may become larger relative to other components in the exemplary device actually manufactured according to the present invention. In the drawings:

[0030] Figure 1 This is a flow chart of a DPU-based K8S cluster multi-NIC service discovery method according to an embodiment of the present application.

[0031] Figure 2 This is a schematic diagram of the architecture of a DPU-based K8S cluster multi-NIC service discovery device according to an embodiment of the present 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 the present application.

[0033] Figure 4 FIG. 1 is a schematic diagram of SRIOV expansion according to an embodiment of the present application. DETAILED DESCRIPTION

[0034] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the embodiments and the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

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

[0036] It should be emphasized that the term “include / comprises” when used herein refers to the presence of features, elements, steps or components, but does not exclude the presence or addition of one or more other features, elements, steps or components.

[0037] It should also be noted here 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, not only to a wired connection, but also to a wireless connection, and the specific connection can be changed based on the actual application scenario.

[0038] In order to better understand the present invention, the terms related to the technical solution are explained as follows:

[0039] Open vSwitch (OVS) is an open source virtual switch that provides high-performance, programmable network forwarding and control planes. It supports multiple network protocols and standards, such as OpenFlow, OVSDB, VXLAN, etc., and can flexibly build and manage virtual networks. The core components of OVS include ovs-vswitchd (data plane) and ovsdb-serer (configuration database; ovs-vswitchd is responsible for packet forwarding and processing, and supports flexible flow table matching and operation; ovsdb-server stores OVS configuration information and provides a programmable interface to manage and query 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 function virtualization) solutions; it is used in conjunction with Kubernetes to achieve highly customized and flexible container networks.

[0040] The controller plays a key role in software-defined networking (SDN) and cloud-native environments. It is a centralized or distributed entity responsible for managing and controlling the behavior of the network. The controller communicates with the data plane (such as OVS) through a southbound interface (such as OpenFlow) to issue forwarding rules and flow tables to achieve programming and dynamic control of the network. In a Kubernetes environment, the network controller is usually integrated with the Kubernetes API Server to listen to Pod and Service change events and adjust the network configuration accordingly. The controller can automatically assign IP addresses, configure networks, generate flow tables, etc. to newly created Pods according to predefined policies and algorithms to achieve automated management of the network. The introduction of the controller improves the flexibility, scalability and intelligence of the network. It decouples the control plane from the data plane of the network, allowing the network to be dynamically configured and optimized in a software-defined manner to adapt to different application requirements and network topologies.

[0041] Container Network Interface (CNI) is the standard and specification of Kubernetes network plug-ins, which defines the interface between container runtime and network plug-ins. It provides a set of APIs and protocols that allow different network plug-ins to be integrated with container runtime to achieve network connection and management of containers. CNI plug-ins describe network configuration information through configuration files (such as JSON format), including network type, IP address range, gateway, etc. When a Pod is created, Kubernetes will call the CNI plug-in to configure the network, assign IP addresses, and connect to the specified network. The design goal of CNI is to provide a simple, pluggable, and composable container network solution. It allows users to select and combine different network plug-ins according to their needs, such as Flannel, Calico, Weave, OVS-CNI, etc., 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 can coordinate and manage other CNI plugins to achieve multi-network connectivity for Pods. In the standard Kubernetes network model, each Pod can only connect to one network, but in some scenarios, a Pod may need to connect to multiple networks at the same time, such as a management network and a data network. Multus-CNI achieves this by creating multiple network interfaces in a Pod, each of which is connected to a different network. When using Multus-CNI, users can declare the multi-network requirements of a Pod through Kubernetes annotations or extended resources (CRDs). Based on the declaration, Multus-CNI calls the underlying CNI plugin to configure the corresponding network interface for the Pod. In addition, it also provides flexible configuration options, such as network priority and bandwidth limit, to meet different application requirements.

[0043] In a traditional K8S cluster, a Pod has only one network card by default, and service discovery is implemented through the kube-proxy component using iptables or IPVS rules. With the complexity of application architecture and the improvement of network performance requirements, some pods are configured with multiple network cards. However, when a Pod is configured with multiple network cards, the conventional service discovery mechanism based on the kube-proxy component cannot work properly. The main reasons are as follows: kube-proxy only recognizes the default network card of the Pod and cannot perceive and manage additional network cards. Multiple network cards in a Pod usually correspond to different IP addresses and network spaces, while abstractions such as Service can only be mapped to the IP of the default network card. Traffic from different network cards may require differentiated forwarding and load balancing strategies, while kube-proxy rules are relatively simple. Forwarding data packets from multiple network cards through kube-proxy will increase additional overhead and affect network performance. Therefore, in the current multi-NIC scenario, the native service discovery function of K8S has many limitations. Developers usually need to manually configure or modify applications to adapt, which greatly increases the complexity of operation and maintenance. Therefore, this application discloses a DPU-based K8S cluster multi-NIC service discovery method, that is, this application introduces an intelligent controller and OVS flow table mechanism to achieve transparent service discovery for K8S multi-NIC Pods. Specifically, the multi-NIC service discovery method of this application automatically identifies the multi-NIC information of the Pod, and generates an OVS flow table according to the preset service policy; dynamically perceives the life cycle changes of the Pod, and adjusts the flow table rules in real time; sends the generated flow table rules to the OVS bridge to achieve second and third layer forwarding and load balancing; and provides flexible flow table matching conditions and processing actions to support differentiated service discovery strategies.

[0044] The multi-NIC service discovery method of the present application solves the multi-NIC service discovery problem through software-defined networking (SDN) without changing the K8S cluster and application, providing a new idea and architecture. Compared with the rule forwarding of kube-proxy, the forwarding based on OVS flow table has the advantages of higher performance, stronger functions, greater flexibility, etc., and is particularly suitable for application scenarios of high-performance networks. At the same time, the present invention gives full play to the global perspective and intelligent scheduling capabilities of the controller, simplifying the management and operation of multiple NICs.

[0045] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. In the accompanying drawings, the same reference numerals represent the same or similar components, or the same or similar steps.

[0046] Figure 1 This is a flow chart of a DPU-based K8S cluster multi-NIC service discovery method according to an embodiment of the present 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 multi-network card information of the pod, where the multi-network card includes a first network card for connecting to the internal network of the K8S cluster and a second network card for connecting to the external network, and the multi-network card information includes network card IP address information.

[0048] In this step, the multi-NIC information of the pod is obtained in real time. The first NIC can be exemplarily the default NIC used to connect to the internal network of the K8S cluster, and the second NIC can be exemplarily an additional NIC used to connect to the external network. In the traditional single NIC scenario, since it only has a default NIC, that is, when publishing Web services through the Service abstraction of K8S and implementing load balancing, a Service named web-service is generally created and mapped to the default NIC IP of Pod 1; in the multi-NIC scenario, since there are additional NICs in addition to the default NIC, there are the following problems: 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 used, wasting network resources.

[0049] The multi-NIC information of the pod can be obtained based on the intelligent controller, that is, the intelligent controller, as a core component, is responsible for monitoring the Kubernetes API Server and obtaining the multi-NIC information of the pod in real time. In addition, the intelligent controller can also monitor the change events of the pod in real time, and dynamically adjust the OVS flow table rules mentioned in the subsequent steps based on the changes of the pod to ensure the real-time 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 automation level of the system.

[0050] Step S20: Determine the virtual IP address information corresponding to the second network card, and generate a forwarding rule 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, a service discovery policy engine is maintained inside the intelligent controller, and corresponding forwarding rules are generated for the Calico network card and OVS network card of each Pod according to the preset service policy. The forwarding rules may exemplarily include the mapping relationship between the network card IP address information and the virtual IP address information, the protocol type, and the operation content; the operation content may exemplarily include modifying the destination MAC, port forwarding, etc. The mapping relationship between the network card IP address information and the virtual IP address information, and the protocol type are used as matching conditions to match the source IP in the request data packet with the destination IP; in this embodiment, the source IP corresponds to the virtual IP address information, and the destination IP is the network card IP address information that matches the virtual IP address information.

[0052] It can be understood that the intelligent controller monitors the change events of resources such as Pod through the K8S API Server, grasps the life cycle and multi-network card information of Pod in real time, and when the Pod changes (such as creation, deletion, migration, etc.), the intelligent controller dynamically adjusts the forwarding rules to 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 card IP address information corresponding to the second network card, and the virtual IP address information, including: generating OVS flow table 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. In this embodiment, the forwarding rules are specifically OVS flow table rules, which may include matching conditions (such as source IP, destination IP, protocol type, etc.) and operation content (such as modifying the destination MAC, port forwarding, etc.; specifically, when the intelligent controller senses the change of the Pod (such as creation, deletion, etc.), according to the preset service discovery rules (such as virtual IP mapping), it automatically generates the corresponding OVS flow table to determine the target network card 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 strategy, no manual intervention is required, thereby improving the degree of automation of service discovery, and thus improving the efficiency of service discovery.

[0054] Step S30: Determine the target network card of the target pod based on the forwarding rule and the request address included in the service call request, and forward the request based on the determined target network card.

[0055] This step can be implemented based on the OVS bridge. The OVS bridge connects the Calico network card (eth0) and the OVS network card (net1) of the Pod, and is responsible for forwarding and processing traffic between them. In the previous step, the intelligent controller sends the generated OVS flow table to the OVS bridge in the cluster through the OVS management protocol (such as OpenFlow), so that the OVS bridge matches and processes according to the OVS flow table rules issued by the intelligent controller. Exemplarily, when an external request accesses the service through the VIP (virtual IP) of the Service, the request data packet is captured by the OVS bridge, and the OVS bridge modifies the destination IP and MAC in the request data packet according to the matching flow table rules, and forwards it to the corresponding network card of the backend Pod; in addition, after the Pod processes the request, the response data packet returns to the original path, and then forwarded to the client by the OVS bridge to achieve transparent service discovery.

[0056] In this step, the OVS bridge applies the OVS flow table rules to process the data packets that match the conditions, and realizes service discovery and load balancing between multiple network cards of the Pod and between the Pod and the outside. The service discovery mechanism based on the controller and the OVS flow table in the above embodiment has the advantages of flexibility, efficiency, and scalability. The intelligent controller grasps the global network status and can dynamically adjust the flow table according to the load conditions to provide more intelligent traffic scheduling; and when the OVS bridge forwards the data packet, it only needs to simply look up the table, without involving complex logic, and has higher performance; at the same time, the flow table rules can be flexibly customized to support richer matching conditions and processing actions to meet the changing service discovery needs.

[0057] In one embodiment, a target network card of a target pod is determined based on a forwarding rule and a request address included in a service call request, and request forwarding is performed based on the determined target network card. Specifically, the OVS bridge determines the target network card corresponding to the request address through a matching algorithm based on an OVS flow table rule; based on the network card IP address information and MAC address information of the target network card, the source IP address and source MAC address in the request data packet are modified to the target IP address and target MAC address; and the modified request data packet is forwarded to the target network card.

[0058] In addition, in order to realize the multi-NIC service discovery of the present application, the Multus-CNI plug-in and the OVS plug-in can be further deployed in the K8S cluster, and / or multiple network cards can be configured for the pod. Specifically, the K8S cluster can integrate multiple network plug-ins through the CNI framework, including Device Plugin Manager, Multus-CNI, Calico-CNI, OVS-CNI and SRIOV-CNI; Multus-CNI is the main plug-in responsible for managing and coordinating other auxiliary plug-ins to realize the multi-NIC configuration of the Pod; Calico-CNI provides ordinary three-layer network connection, OVS-CNI provides an overlay network based on OVS, and SRIOV-CNI provides a high-performance direct network. In this embodiment, SRIOV technology is integrated to provide a high-performance direct network option.

[0059] When declaring and configuring multiple network cards for a pod, the cluster administrator can declare multiple network cards for the pod through the K8S network attachment mechanism (such as Annotation). Multiple network cards can include Calico, OVS, and SRIOV types at the same time; Figure 3 As shown in the figure, Multus-CNI configures the corresponding network interfaces for the Pod according to the declaration, including the Calico network card (eth0), OVS network card (net1) and SRIOV network card (net2). In addition, the Pod can connect to multiple networks at the same time to achieve flexible multi-network communication.

[0060] In the above embodiment, the OVS flow table mechanism is introduced to achieve 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; the flow table rules are dynamically generated and updated by the intelligent controller, which reduces the workload of manual configuration and improves the efficiency of service discovery.

[0061] In a specific embodiment, assume that a multi-layer web application is deployed in a K8S 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, two network cards are configured for both Pod 1 and Pod 2. Figure 2 As shown in the figure: the default network card eth0 is connected to the internal network of the K8S cluster and is used to communicate with other Pods. The IP addresses are 10.244.0.10 and 10.244.0.20 respectively; the additional network card eth1 is connected to the external network and is used to communicate with clients or other external services. The IP addresses are 192.168.1.10 and 192.168.1.20 respectively. When publishing Web services through the K8S Service abstraction, in order to achieve load balancing and ensure that additional network cards are discovered and used, Multus-CNI and OVS plug-ins are deployed in the K8S cluster, and intelligent controllers are deployed to monitor Pod change events in K8S; the intelligent controller perceives Pod 1 and Pod 2 is created, according to the preset service discovery strategy, the following OVS flow table rules are automatically generated: #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 further sends 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, and then the destination IP and MAC address in the request packet will be modified to the corresponding values ​​of eth1 of Pod 1, and finally forwarded to Pod 1 for processing; in addition, after Pod1 processes the request, the response packet returns along the original route and is then forwarded to the client by the OVS bridge.

[0062] In another embodiment, the DPU-based K8S cluster multi-NIC service discovery method also 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 the pod changes, the OVS flow table rules are dynamically adjusted to ensure the real-time and accuracy of service discovery; and 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 plug-ins provide a consistent network configuration and management interface, simplifying the complexity of operation and maintenance in a multi-network environment; the above embodiment is transparent to the existing Kubernetes architecture and applications, does not require modification of application code, and reduces migration and usage costs.

[0063] In addition, in addition to dynamically updating the OVS flow table, the intelligent controller can also distribute requests among multiple backend Pods according to load balancing strategies (such as Round-Robin, Least-Connection, etc.) to achieve horizontal expansion of services. From the above content, it can be seen that the intelligent controller implements service discovery and load balancing by sending the generated flow table rules to the OVS bridge; and through flexible flow table matching conditions and processing actions, it supports multiple service discovery and load balancing strategies, improving the scalability of the solution.

[0064] Correspondingly, the present invention also provides a DPU-based K8S cluster multi-network card service discovery device, the device comprising a processor, a memory and a computer program stored in the memory, the processor is used to execute the computer program, and when the computer program is executed, the device implements the steps of the method described in any of the above embodiments.

[0065] In the above-mentioned multi-NIC service discovery device, an expansion interface for integrating high-performance network technology (such as SRIOV) is reserved to meet the scenario with higher requirements for network performance. The SRIOV expansion diagram is as follows: Figure 4 As shown. And by adding a dedicated CNI plug-in (such as SRIOV-CNI) and the corresponding device plug-in, the device can integrate high-performance network cards such as SRIOV into the solution. In addition, the intelligent controller can monitor the information of the high-performance network card and adjust the OVS flow table accordingly to forward the service request to the high-performance network card.

[0066] Through the above embodiments, it can be found that the DPU-based K8S cluster multi-network card service discovery method and device of the present application realize the coordination and integration of multiple CNI plug-ins, that is, multiple network plug-ins are integrated through the CNI framework, including Calico-CNI, OVS-CNI and SRIOV-CNI, etc., thereby providing rich network connection options to meet the network requirements in different scenarios; Multus-CNI is used as the main plug-in to manage and coordinate other auxiliary plug-ins, thereby realizing the multi-network card configuration of the Pod; different types of network cards can be connected to the Pod at the same time to meet the network performance and flexibility requirements of different applications; the coordination and integration of multiple CNI plug-ins 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 realize transparent service discovery and load balancing. Specifically, through the flexible matching and forwarding of OVS flow table rules, transparent service discovery of multiple Pod network cards is realized; external requests access services through the Service's VIP, and the OVS bridge forwards the requests to the backend Pod according to the flow table rules without modifying the application; the controller supports multiple load balancing strategies and can distribute requests among multiple backend Pods as needed to achieve horizontal expansion of services; the intelligent controller supports flexible transparent service discovery strategies and load balancing algorithms, which can be customized and expanded according to business needs; the decoupling design of core components, such as the decoupling of intelligent controllers and OVS flow tables, improves the scalability and maintainability of the solution.

[0068] In addition, the multi-NIC service discovery method disclosed in this application retains the abstract concepts of Kubernetes native Service, Endpoint, etc. Existing applications can be migrated smoothly without modifying the code, and the upper-level applications do not need to perceive changes in the underlying network implementation; the controller is integrated with the Kubernetes API Server to monitor and manage the life cycle events of the Pod through a standard API interface; the configuration and management of multiple network cards are transparent to the application and do not affect the conventional network configuration and management processes; it is compatible with Kubernetes native abstractions, ensuring the smooth integration and transition of the solution in the existing architecture, reducing the cost of application migration; and this method is integrated with the Kubernetes API Server, and the technical solution is seamlessly connected with existing management tools and processes, reducing the cost of operation and maintenance learning.

[0069] In summary, the DPU-based K8S cluster multi-NIC service discovery method and device of the present application, by introducing the mapping of virtual IP (VIP) to real IP, and using OVS flow table to realize request forwarding, realizes transparent service discovery of K8S multi-NIC Pod. In the above embodiment, external clients can directly access internal services through VIP without going through complex operations such as NAT; the multi-NIC capabilities of Pod are fully utilized, and the traffic of different NICs can be isolated and processed; the service discovery strategy is implemented through flow table rules, which is flexible and configurable, and can support more complex load balancing algorithms; the forwarding function is efficiently completed in the OVS kernel, and the performance is better; the controller automatically generates and synchronizes flow tables, which simplifies operation and maintenance and improves reliability. Therefore, it can be found that the present application cleverly uses SDN and OVS technologies to break through the limitations of K8S service discovery, and provides strong support for cloud-native applications in complex network environments, making the management and use of multi-NIC Pods more intelligent and efficient.

[0070] The embodiments of the present invention also provide a computer-readable storage medium and a computer program product, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the method described in any of the above embodiments are implemented. The computer-readable storage medium can be a tangible storage medium, such as a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a floppy disk, a hard disk, a removable storage disk, a CD-ROM, or any other form of storage medium known in the technical field.

[0071] It should be understood by those skilled in the art 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 the two. Whether it is performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), appropriate firmware, a plug-in, a function card, etc. When implemented in software, the elements of the present invention are programs or code segments used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link via a data signal carried in a carrier.

[0072] It should be clear that the present invention is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is 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, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present invention.

[0073] In the present 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 features of other embodiments or replace features of other embodiments.

[0074] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the embodiments of the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A DPU-based K8S cluster multi-NIC service discovery method, characterized in that: The service discovery method includes: Get the service call request and the multi-NIC information of the pod, where 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 card, and generate a forwarding rule based on the preset service policy, the network card IP address information corresponding to the second network card, and the virtual IP address information; The target network card 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 card.

2. According to the DPU-based K8S cluster multi-NIC service discovery method according to claim 1, it is characterized in that: Generate a forwarding rule based on the preset service policy, the network card IP address information corresponding to the second network card, and the virtual IP address information, including: Generate OVS flow table 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.

3. According to the DPU-based K8S cluster multi-NIC service discovery method according to claim 2, it is characterized in that: The target network card of the target pod is determined based on the forwarding rule and the request address contained in the service call request, and the request is forwarded based on the determined target network card, including: 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 network card IP address information and MAC address information of the target network card, the source IP address and the source MAC address in the request data packet are modified to the target IP address and the target MAC address; The modified request data packet is forwarded to the target network card.

4. The DPU-based K8S cluster multi-NIC service discovery method according to claim 1 is characterized in that: The method further comprises: Deploy the Multus-CNI plug-in and OVS plug-in in the K8S cluster.

5. The DPU-based K8S cluster multi-NIC service discovery method according to claim 1 is characterized in that: The method further comprises: Configure multiple network interfaces for the pod.

6. The DPU-based K8S cluster multi-NIC service discovery method according to claim 3 is characterized in that: The method further includes: obtaining a pod deployment request, and updating the OVS flow table rule based on the obtained pod deployment request; and / or, Obtain a response data packet, and forward the response data packet based on the OVS bridge.

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

8. A DPU-based K8S cluster multi-network card 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. When the computer program is executed, the device implements the steps of the method according to any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images