Node-level configuration delivery method and device for centralized service mesh

Abstract

The application provides a node-level configuration issuing method and device of a centralized service grid, and relates to the technical field of computers, the method is applied to a node agent deployed on a node, the node agent is connected with a control plane of the centralized service grid and a data plane located on a DPU respectively, the node agent maintains XDS configuration resources in real time by listening to pod changes on the node, the XDS configuration resources are used for recording XDS information of all pods of the node, and the XDS configuration resources are provided with a specified field recording a node identifier; the method comprises the following steps: receiving a configuration acquisition request sent by the data plane; sending an issued configuration request to the control plane by adding target identity information with the node identifier; and forwarding target XDS configuration returned by the control plane to the data plane. The application realizes node-level configuration issuing without modifying the control plane of the centralized service grid.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and apparatus for distributing node-level configurations in a centralized service mesh. Background Technology

[0002] A service mesh serves as the infrastructure layer for communication between cloud-native microservices, controlling how different parts of an application share data. It typically consists of two components: a control plane and a data plane. The control plane handles functions such as service discovery, load balancing, traffic management, and health checks, while the data plane is responsible for the actual request forwarding and processing.

[0003] Traditional service meshes employ a sidecar deployment model, where each microservice is configured with its own sidecar. The sidecar, acting as the service mesh's data plane, resides within the same Kubernetes (container orchestration platform) cluster as the service mesh's control plane. Because sidecars consume significant host resources, microservice latency is greatly increased, and traffic processing efficiency is reduced. This led to the development of a centralized service mesh model with a one-to-many mechanism. This model offloads the centralized service mesh to a Data Processing Unit (DPU). All microservice traffic on a node is processed and forwarded by a centralized proxy on the corresponding DPU, improving forwarding efficiency and reducing network latency. The DPU is a data-centric, I / O-intensive next-generation computing chip that uses software-defined technologies to support infrastructure resource layer virtualization. It improves computing system efficiency, reduces the overall total cost of ownership, enhances data processing performance, and reduces performance overhead on other computing chips. The sidecar deployment model and the centralized service mesh architecture offloaded to the DPU are illustrated below. Figure 1 As shown.

[0004] Service meshes use XDS (Extensible Discovery Service) to manage and configure proxies. In sidecar deployment mode, each proxy has its own identity. When the service mesh control plane distributes configurations, it identifies this identity and then distributes the associated XDS configuration to the proxy. The proxy forwards and processes traffic based on the XDS configuration, thus achieving fine-grained resource distribution and isolation. For centralized service meshes, proxies need to obtain the configurations of all services on their node to achieve traffic governance for all services on that node. How to enable the service mesh control plane to assemble the configurations of all services and distribute them to the corresponding proxies is a major problem that centralized service meshes must solve. Summary of the Invention

[0005] The purpose of this invention is to provide a method and apparatus for distributing node-level configurations in a centralized service mesh, so as to achieve node-level configuration distribution without modifying the centralized service mesh control plane.

[0006] In a first aspect, the present invention provides a node-level configuration distribution method for a centralized service mesh, applied to a node agent deployed on a node. The node agent is connected to both the control plane of the centralized service mesh and the data plane located on the DPU. The node agent maintains XDS configuration resources in real time by monitoring changes in the pods on its node. The XDS configuration resources are used to record the XDS information of all pods on the node, and the XDS configuration resources are set with a specified field for recording node identifiers. The method includes:

[0007] Receive configuration retrieval requests sent by the data plane;

[0008] A configuration request is sent to the control plane with the target identity information containing node identifiers, so that the control plane returns the target XDS configuration corresponding to the XDS configuration resource based on the target identity information in the configuration request;

[0009] Receive the target XDS configuration and forward it to the data plane.

[0010] In an optional implementation, a configuration request is sent to the control plane using target identity information with added node identifiers, including:

[0011] Retrieve the initial identity information from the configuration retrieval request;

[0012] Determine whether the initial identity information contains a node identifier;

[0013] If the initial identity information does not contain a node identifier, the node identifier is added to the initial identity information of the configuration retrieval request to obtain a configuration request with the target identity information.

[0014] Send the configuration request to the control plane.

[0015] In an optional implementation, before determining whether the initial identity information contains a node identifier, the above method further includes:

[0016] Send a node identifier retrieval request to the K8s API server in the control plane;

[0017] Receive the node identifier returned by the K8s API server.

[0018] In an optional implementation, the method further includes:

[0019] Monitor changes to pods on the local node in real time;

[0020] When a pod change is detected, a pod information query request is sent to the K8s API server in the control plane;

[0021] Receive the target pod information returned by the K8s API server;

[0022] Update XDS configuration resources based on the target pod information.

[0023] In an optional implementation, updating the XDS configuration resources based on the target pod information includes:

[0024] Based on the node identifier in the target pod information, determine whether the target pod that has changed is located on the node where the node agent is located;

[0025] If the target pod is located on the node where the node agent is located, add the pod change event of the target pod to the processing queue;

[0026] Retrieve pod change events from the processing queue, and process the target pod and update XDS configuration resources according to the event type of the pod change event.

[0027] In an optional implementation, the target pod is processed and XDS configuration resources are updated based on the event type of the pod change event, including:

[0028] When the event type is a deletion event, delete the XDS information of the corresponding pod in the XDS configuration resource;

[0029] When the event type is an add event or an update event, create the target resource corresponding to the pod change event, and add or update the corresponding pod XDS information in the XDS configuration resource according to the target resource; the target resource includes listener, cluster, route and endpoint.

[0030] Secondly, the present invention provides a node-level configuration distribution device for a centralized service mesh, applied to node agents deployed on nodes. The node agents are connected to both the control plane of the centralized service mesh and the data plane located on the DPU. The node agents maintain XDS configuration resources in real time by monitoring changes in the pods on their respective nodes. The XDS configuration resources are used to record the XDS information of all pods on the node, and the XDS configuration resources are configured with a specified field for recording node identifiers. The device includes:

[0031] The first receiving module is used to receive configuration acquisition requests sent by the data plane;

[0032] The first sending module is used to send a configuration request to the control plane with the target identity information containing the node identifier, so that the control plane can return the target XDS configuration corresponding to the XDS configuration resource according to the target identity information in the configuration request.

[0033] The second receiving module is used to receive the target XDS configuration;

[0034] The second sending module is used to forward the target XDS configuration to the data plane.

[0035] Thirdly, the present invention provides an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement any of the methods described in the foregoing embodiments.

[0036] Fourthly, the present invention provides a node-level configuration distribution system for a centralized service mesh, including a centralized service mesh and node agents deployed on nodes. The centralized service mesh includes a control plane and a data plane located on a DPU, and the control plane and the data plane are respectively connected to the node agents.

[0037] After receiving a configuration retrieval request from the data plane, the node agent sends a configuration request to the control plane with the target identity information containing the node identifier. The node agent maintains the XDS configuration resource in real time by listening to changes in the pods on its node. The XDS configuration resource is used to record the XDS information of all pods on the node, and the XDS configuration resource has a specified field for recording the node identifier.

[0038] The control plane is used to receive a configuration request and, based on the target identity information in the configuration request, return the target XDS configuration corresponding to the XDS configuration resource.

[0039] The node agent is also used to forward the target XDS configuration to the data plane after receiving the target XDS configuration.

[0040] In an optional implementation, the control plane is also used to monitor changes to XDS configuration resources via the K8s API server; when a change to the XDS configuration resource is detected, the current XDS configuration resource is validated for legality; after successful validation, a specified field of the current XDS configuration resource is parsed to obtain the node identifier, thereby determining the node proxy for which the current XDS configuration resource is applied; and the target XDS configuration is generated based on the XDS information of all pods recorded in the current XDS configuration resource.

[0041] The centralized service mesh node-level configuration distribution method and apparatus provided by this invention includes a control plane and a data plane located on the DPU. The control plane and the data plane are respectively connected to node agents deployed on nodes. After receiving a configuration acquisition request from the data plane, the node agent sends a configuration distribution request to the control plane with target identity information including node identifier. The node agent maintains XDS configuration resources in real time by monitoring changes in pods on its node. The XDS configuration resources are used to record the XDS information of all pods on the node and have a specified field for recording node identifiers. After receiving the configuration distribution request, the control plane returns the target XDS configuration corresponding to the XDS configuration resource according to the target identity information in the configuration distribution request. After receiving the target XDS configuration, the node agent forwards the target XDS configuration to the data plane.

[0042] By incorporating target identity information with node identifiers, a node-level proxy identity is provided. Proxyes using this identity will only obtain the XDS configurations of all pods on their local node, unaffected by the configurations of pods on other nodes. Based on this node-level proxy identity, an XDS configuration resource is constructed to record the XDS information of all pods on the local node and is maintained in real time. This allows the control plane to distribute node-level XDS configurations upon recognizing the XDS configuration resource. This approach enables the control plane to directly distribute the XDS configurations of all pods on the local node without any modifications, achieving node-level configuration distribution, maintaining compatibility with the native control plane, and adapting to various network scenarios. Furthermore, the maintenance of the XDS configuration resource is real-time; as pods change, the XDS configuration resource is updated accordingly, ensuring the correctness and effectiveness of the XDS configurations. Attached Figure Description

[0043] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0044] Figure 1 A schematic diagram of the architecture for the sidecar deployment mode and the centralized service mesh;

[0045] Figure 2 A flowchart illustrating a node-level configuration distribution method for a centralized service mesh provided in an embodiment of the present invention;

[0046] Figure 3 A schematic diagram of a centralized service mesh architecture provided in an embodiment of the present invention;

[0047] Figure 4 An interactive flowchart for node-level configuration distribution is provided in an embodiment of the present invention;

[0048] Figure 5 A flowchart for handling pod change events provided in an embodiment of the present invention;

[0049] Figure 6 A schematic diagram of a node-level configuration distribution device for a centralized service mesh provided in an embodiment of the present invention;

[0050] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention;

[0051] Figure 8 This is a schematic diagram of the structure of a node-level configuration distribution system for a centralized service mesh, provided as an embodiment of the present invention. Detailed Implementation

[0052] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0053] In the sidecar deployment mode, each sidecar manages one pod (one pod corresponds to one microservice). Therefore, the sidecar only needs to obtain the configuration of the corresponding pod to process the traffic entering and leaving the pod. When the sidecar obtains the XDS configuration, it uses a pod-level identity to ensure that the XDS configuration is only related to the corresponding pod.

[0054] As the number of services increases, the number of sidecars also grows year-on-year, further consuming host resources. Simultaneously, the service mesh control plane needs to maintain and process a large number of identity-XDS resource mapping relationships, making the management of sidecar identities increasingly complex. Existing technologies use pod-level identities; continuing to use pod-level identities in a centralized service mesh does not allow the control plane to directly distribute node-level XDS configurations. Therefore, this invention provides a node-level configuration distribution method and apparatus for a centralized service mesh. It provides a node-level identity and utilizes the resource interface provided by the service mesh control plane to create a resource storing the configurations of all pods on the node. The control plane identifies the configurations through the resource interface, assembles the configurations of each pod, and distributes them to the corresponding agents. This solves both the problem of managing a large number of complex identities in existing technologies and the problem of existing technologies not supporting node-level configuration distribution.

[0055] To facilitate understanding of this embodiment, a detailed description of a node-level configuration distribution method for a centralized service mesh disclosed in this embodiment of the invention will be provided first.

[0056] This invention provides a node-level configuration distribution method for a centralized service mesh. This method is applied to node agents deployed on nodes. The node agents are connected to both the control plane and the data plane located on the DPU (Data Processing Unit) of the centralized service mesh. The data plane is also the centralized agent. The node agents maintain XDS (Extended Node Configuration Resource) resources in real time by monitoring changes to the pods on their respective nodes. The XDS resources record the XDS information of all pods on the node and include a specified field for recording node identifiers. The node agents can be deployed using DaemonSets to ensure one agent runs per node. Optionally, the control plane can use Istio, the data plane can use Envoy, and the node identifier can be the node name.

[0057] See Figure 2 The diagram shows a flowchart of a node-level configuration distribution method for a centralized service mesh. This method mainly includes the following steps S210 to S230:

[0058] Step S210: Receive the configuration acquisition request sent by the data plane.

[0059] After the data plane establishes a connection with the node agent and the node agent establishes a connection with the control plane, the node agent can intercept the configuration request when the data plane requests configuration from the control plane.

[0060] Step S220: Send a configuration request to the control plane with the target identity information containing the node identifier, so that the control plane returns the target XDS configuration corresponding to the XDS configuration resource based on the target identity information in the configuration request.

[0061] The node proxy can parse the configuration acquisition request, modify the initial identity information obtained from the parsing, and use the new identity with the added node identifier to request the control plane to distribute the configuration.

[0062] In some possible embodiments, step S220 above may include: obtaining initial identity information in the configuration acquisition request; determining whether the initial identity information contains a node identifier; if the initial identity information does not contain a node identifier, adding the node identifier to the initial identity information of the configuration acquisition request to obtain a configuration request with target identity information; if the initial identity information contains a node identifier, the configuration acquisition request can be directly used as a configuration request; and sending the configuration request to the control plane.

[0063] Considering that the node agent has not yet obtained the node identifier after the node agent establishes an initial connection with the control plane, the above method further includes, before determining whether the initial identity information contains the node identifier: sending a node identifier acquisition request to the K8s API server of the control plane; and receiving the node identifier returned by the K8s API server.

[0064] The control plane can identify the target identity information in the configuration request, determine the corresponding XDS configuration resource based on the node identifier in the target identity information, convert the XDS information of all pods in the XDS configuration resource into the target XDS configuration at the node level, and then return it to the node agent.

[0065] Step S230: Receive the target XDS configuration and forward the target XDS configuration to the data plane.

[0066] After receiving the target XDS configuration returned by the control plane, the node agent will forward the target XDS configuration to the data plane, so that the data plane can obtain the node-level configuration.

[0067] Furthermore, this embodiment of the invention also provides a method for updating XDS configuration resources. This method may further include: real-time monitoring of pod changes on the node; when a pod change is detected, sending a pod information query request to the K8s API server in the control plane; receiving target pod information returned by the K8s API server; and updating the XDS configuration resources based on the target pod information. Pod changes may include additions, updates, or deletions; that is, whenever a pod is added, updated, or deleted, the XDS configuration resources will be updated.

[0068] To ensure the correctness and effectiveness of XDS configuration resource updates, the above-mentioned update of XDS configuration resources based on target pod information can include: determining whether the target pod with changes is located on the node agent node based on the node identifier in the target pod information; if the target pod is located on the node agent node, adding the target pod's pod change event to the processing queue; retrieving the pod change event from the processing queue, and processing the target pod and updating the XDS configuration resources according to the event type of the pod change event. This ensures that only the XDS information of pods on the local node is updated.

[0069] Event types can include add events, update events, or delete events. Different event types have different update methods. Based on this, the above-mentioned processing of the target pod and updating of XDS configuration resources according to the event type of the pod change event can include: when the event type is a delete event, deleting the XDS information of the corresponding pod in the XDS configuration resource; when the event type is an add event or an update event, creating the target resource corresponding to the pod change event, and adding or updating the corresponding pod XDS information in the XDS configuration resource according to the target resource; where the target resource includes listener, cluster, route, and endpoint.

[0070] In practice, the node agent sequentially calls the LDS (Local Data Service), CDS (Central Data Service), RDS (Remote Data Service), and EDS (Enterprise Data Service) processing modules to create resources such as listener, cluster, route, and endpoint. After these resources are created, the event type is checked again. If it is an add event, the node agent adds these resources to the XDS configuration resources. If it is an update event, the node agent compares the old and new resources to determine if there are any changes. If there are changes, the XDS configuration resources are updated by replacing the old resources with the new ones. If there are no changes, the XDS configuration resources are not updated.

[0071] Furthermore, the control plane can generate node-level target XDS configurations based on updates to XDS configuration resources. Specifically, the control plane can monitor changes to XDS configuration resources through the Kubernetes API server; when a change is detected, the control plane performs validity checks on the current XDS configuration resource, such as checking for syntax errors or missing fields; after successful verification, it parses specified fields of the current XDS configuration resource to obtain the node identifier, thereby determining the node proxy for which the current XDS configuration resource applies; and based on the XDS information of all pods recorded in the current XDS configuration resource, it generates the target XDS configuration.

[0072] In this embodiment of the invention, target identity information with node identifiers is added, providing a node-level proxy identity. A proxy using this identity will only obtain the XDS configurations of all pods on its local node and will not be affected by the pod configurations on other nodes. Based on the node-level proxy identity, an XDS configuration resource is constructed to record the XDS information of all pods on the local node and is maintained in real time. This allows the control plane to distribute node-level XDS configurations after recognizing the XDS configuration resource. Thus, without making any modifications to the control plane, the control plane directly distributes the XDS configurations of all pods on the local node, achieving node-level configuration distribution, maintaining compatibility with the native control plane, and adapting to various network scenarios. Furthermore, the maintenance of the XDS configuration resource is real-time; when pods change, the XDS configuration resource is updated accordingly, ensuring the correctness and effectiveness of the XDS configuration.

[0073] Taking xdsProxy as the node proxy and the node name as the node identifier as an example, the two technical challenges and their solutions in the node-level configuration distribution method of the centralized service mesh provided in this embodiment of the invention include:

[0074] 1. How to construct a proxy node-level identity and ensure that this identity is only related to all pods on this node.

[0075] A service called xdsProxy is deployed on each node to intercept and modify the identity of the centralized proxy. Since the identity of each centralized proxy needs to be modified, the xdsProxy service must exist on every node. Kubernetes stores the xdsProxy service and the node name (nodeName) of the pod in etcd. The xdsProxy service on the same node has the same nodeName as the pod; this issue is resolved by simply adding the nodeName information to the centralized proxy's identity. etcd is a distributed, reliable key-value store primarily used for maintaining and managing configuration data, state information, and service discovery within the cluster.

[0076] 2. How to use this node-level identity to allow the control plane to issue node-level configurations.

[0077] After the identity is modified, the centralized proxy will use this new identity to interact with the control plane. xdsProxy will monitor changes to all pods on this node and maintain a network configuration resource (i.e., XDS configuration resource) containing all pods on this node. The control plane provides many resource interfaces for extending or modifying the proxy configuration. Through these interfaces, the control plane can obtain this network configuration resource and then transform it, that is, assemble the XDS information of each pod to form a node-level XDS configuration, which is then distributed to the corresponding centralized proxy.

[0078] The following section uses Istio as an example for the control plane, Envoy as an example for the data plane, dpu-xds-config as an example for XDS configuration resources, workSelectorLabel as an example for specified fields, and nodeName as an example for node identifiers to provide an exemplary description of the node-level configuration distribution method for the above centralized service mesh.

[0079] (1) Deploy a centralized service mesh environment and xdsProxy service. The xdsProxy service is deployed using the Daemonset method to ensure that one node runs one service.

[0080] (2) Envoy reads the configuration file and initializes it.

[0081] (3) Envoy establishes a connection with xdsProxy, and xdsProxy establishes a connection with Istio.

[0082] (4) Envoy request configuration: xdsProxy intercepts the request and obtains the identity information in the request. If the nodeName of xdsProxy is not in the identity information, xdsProxy will add the nodeName to the identity information.

[0083] (5) xdsProxy uses the new identity to request Istio to distribute the configuration.

[0084] (6) At the same time, xdsProxy will create a dpu-xds-config resource and set a workSelectorLabel field with xdsProxy nodeName for it. It will also maintain the dpu-xds-config resource by listening for pod changes. This resource is used to record the XDS information of all pods on this node.

[0085] (7) When a pod changes (Add / Delete / Update), xdsProxy sends a request to the Kubernetes API server to query the pod's IP address, Name (resource name), Namespace, nodeName, and other information. xdsProxy first checks if the pod's nodeName is equal to xdsProxy's nodeName. If they are equal, the change is stored in a queue. xdsProxy then retrieves events from the queue sequentially and processes them. The specific processing procedure will be described in detail later.

[0086] After xdsProxy processes dpu-xds-config, Istio internally aggregates its contents and converts them into node-level XDS configurations. The detailed process is as follows: Istio monitors for changes to the dpu-xds-config resource via the Kubernetes API server. Once a change is detected, it first verifies the validity of dpu-xds-config, checking for syntax errors or missing fields. If valid, Istio further parses the workSelectorLabel field in dpu-xds-config to determine the pod it applies to. Since xdsProxy uses the nodeName of the node where dpu-xds-config resides in the workSelectorLabel field, the scope of dpu-xds-config is all pods on the current node. Istio then generates the corresponding XDS configuration (such as Listener, Cluster, Route, etc.) based on the content of the nodeXDS field in dpu-xds-config. The nodeXDS field records the XDS information for all pods on the current node.

[0087] (8) Istio selects the node agent whose identity is nodeName from the node agents that have established a connection and sends out the XDS configuration by recognizing the nodeName information in the workSelectorLabel.

[0088] Figure 3 This is a schematic diagram of a centralized service mesh architecture. Figure 3 This describes the location of xdsProxy within the overall architecture; it resides on each worker node in the Kubernetes cluster (i.e., Figure 3On the K8s-node of the DPU service mesh, it needs to interact with both the control plane component istio and the K8s API Server (i.e., the K8s API server) of the DPU service mesh, and with the centralized agent envoy on the DPUSoC (System On Chip) side. Both istio and the K8s API Server reside on the master node of the Kubernetes cluster (i.e., the K8s-node). Figure 3 It runs on the K8s-master. xdsProxy has two main functions: one is identity modification, which modifies the identity information in the request sent by Envoy when requesting configuration from Istio; the other is node-level configuration construction, which maintains the dpu-xds-config resource, which Istio will eventually convert into node-level XDS configuration and return to Envoy.

[0089] Figure 4 This is an interactive flowchart for node-level configuration distribution. Figure 4 This describes how Envoy (the centralized proxy) interacts with Istio (the control plane of the service mesh on the DPU) and the Kubernetes API server to obtain configuration information in a DPU service mesh environment via xdsProxy (the node proxy). The following is a detailed step-by-step description:

[0090] 1. Load configuration and initialize: Envoy first loads its configuration and initializes it.

[0091] 2. Establish connection: Envoy attempts to establish a connection with xdsProxy.

[0092] 3. Connection established successfully: xdsProxy confirms that the connection was established successfully and sends a success message back to Envoy.

[0093] 4. Establish connection: xdsProxy attempts to establish a connection with Istio.

[0094] 5. Connection established successfully: Istio confirms that the connection has been established successfully and sends a success message back to xdsProxy.

[0095] 6. Send a request to request configuration information: Envoy sends a request to xdsProxy to request configuration information.

[0096] 7. Get nodeName: xdsProxy sends a request to the K8s API server to get its own nodeName (node ​​name).

[0097] 8. Return nodeName: The K8s API server returns the nodeName to xdsProxy.

[0098] 9. Modify the identity information in the request from Envoy: xdsProxy modifies the identity information in the request by adding nodeName.

[0099] 10. Send a request with the new identity, requesting configuration: xdsProxy sends this request to Istio, requesting Istio configuration.

[0100] 11. Identify identity: Istio identifies the identity information in the request.

[0101] 12. Configuration Distribution: Istio distributes the configuration information to xdsProxy based on the identity information.

[0102] 13. Forward to Envoy: xdsProxy forwards the configuration obtained from Istio to Envoy.

[0103] Figure 5 A flowchart for handling pod change events is provided as an embodiment of the present invention, such as... Figure 5 As shown, after xdsProxy detects a pod change, it determines whether the changed pod and xdsProxy are on the same node. If they are not on the same node, the process ends and no operation is performed. If they are on the same node, xdsProxy adds the pod change event to a processing queue. Subsequently, it retrieves pod change events from the processing queue and determines the next operation based on the event type (add, update, or delete). If it is a delete event, xdsProxy directly deletes the corresponding pod XDS information in dpu-xds-config. If it is an add or update event, it sequentially calls the xdsProxy's LDS, CDS, RDS, and EDS processing modules to create resources such as listeners, clusters, routes, and endpoints. After the resources are created, the event type is checked again. If it is an add event, xdsProxy will add these resources to dpu-xds-config. If it is an update event, xdsProxy will compare the old and new resources to determine if there are any changes. If there are changes, the resources will be updated in dpu-xds-config. If there are no changes, the process ends and no operation is performed.

[0104] In summary, this embodiment of the invention employs a centralized proxy, with the service mesh data plane located on the SoC side of the DPU, no longer on the host, thus saving host resources. By adding nodeName information to the identity information, a node-level proxy identity is provided. A proxy using this identity will only obtain the XDS configuration of all pods on its own node and will not be affected by the pod configurations on other nodes. Based on the node-level identity, the network configuration dpu-xds-config of all pods on the same node is constructed and maintained in real time. After Istio recognizes this configuration, it transforms and assembles the configuration and distributes the node-level configuration to the proxy.

[0105] The embodiments of the present invention have the following advantages: (1) The centralized agent is located on the DPU, which saves host resources. Compared with the sidecar deployment mode, the number of agents is reduced, and the business traffic entering and leaving the host is forwarded and processed by the centralized agent on the DPU; (2) The native Istio does not support the distribution of node-level XDS configuration. The embodiments of the present invention allow Istio to distribute the configuration of all pods on the local node without making any modifications to Istio, maintaining compatibility with the native Istio and adapting to various network scenarios; (3) The maintenance of dpu-xds-config is real-time. When the pod changes, dpu-xds-config will also be updated accordingly, ensuring the correctness and effectiveness of the agent XDS configuration.

[0106] Corresponding to the above-described centralized service mesh node-level configuration distribution method, this embodiment of the invention also provides a centralized service mesh node-level configuration distribution device. This device is applied to a node agent deployed on a node. The node agent is connected to the control plane of the centralized service mesh and the data plane located on the DPU. The data plane is also the centralized agent. The node agent maintains the XDS configuration resource in real time by listening to changes in the pods on the node. The XDS configuration resource is used to record the XDS information of all pods on the node. The XDS configuration resource is set with a specified field for recording node identifiers.

[0107] See Figure 6 The diagram shows a structural schematic of a node-level configuration distribution device for a centralized service mesh. The device includes:

[0108] The first receiving module 601 is used to receive configuration acquisition requests sent by the data plane;

[0109] The first sending module 602 is used to send a configuration request to the control plane with the target identity information containing the node identifier, so that the control plane returns the target XDS configuration corresponding to the XDS configuration resource according to the target identity information in the configuration request.

[0110] The second receiving module 603 is used to receive the target XDS configuration;

[0111] The second sending module 604 is used to forward the target XDS configuration to the data plane.

[0112] In this embodiment of the invention, target identity information with node identifiers is added, providing a node-level proxy identity. A proxy using this identity will only obtain the XDS configurations of all pods on its local node and will not be affected by the pod configurations on other nodes. Based on the node-level proxy identity, an XDS configuration resource is constructed to record the XDS information of all pods on the local node and is maintained in real time. This allows the control plane to distribute node-level XDS configurations after recognizing the XDS configuration resource. Thus, without making any modifications to the control plane, the control plane directly distributes the XDS configurations of all pods on the local node, achieving node-level configuration distribution, maintaining compatibility with the native control plane, and adapting to various network scenarios. Furthermore, the maintenance of the XDS configuration resource is real-time; when pods change, the XDS configuration resource is updated accordingly, ensuring the correctness and effectiveness of the XDS configuration.

[0113] Furthermore, the first sending module 602 is specifically used to: obtain the initial identity information in the configuration acquisition request; determine whether the initial identity information contains a node identifier; if the initial identity information does not contain a node identifier, add the node identifier to the initial identity information of the configuration acquisition request to obtain a configuration request with target identity information; and send the configuration request to the control plane.

[0114] Furthermore, the above-mentioned device also includes an acquisition module, which is used to: send a node identifier acquisition request to the K8s API server in the control plane; and receive the node identifier returned by the K8s API server.

[0115] Furthermore, the above-mentioned device also includes an update module, which is used to: monitor pod changes on the node in real time; when a pod change is detected, send a pod information query request to the K8s API server in the control plane; receive the target pod information returned by the K8s API server; and update the XDS configuration resources according to the target pod information.

[0116] Furthermore, the aforementioned update module is specifically used to: determine whether the target pod with changes is located on the node agent node based on the node identifier in the target pod information; if the target pod is located on the node agent node, add the target pod change event to the processing queue; retrieve the pod change event from the processing queue, and process the target pod and update the XDS configuration resources according to the event type of the pod change event.

[0117] Furthermore, the update module is also used to: when the event type is a deletion event, delete the XDS information of the corresponding pod in the XDS configuration resource; when the event type is an addition event or an update event, create the target resource corresponding to the pod change event, and add or update the corresponding pod XDS information in the XDS configuration resource according to the target resource; wherein, the target resource includes listener, cluster, route and endpoint.

[0118] The device provided in this embodiment has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0119] like Figure 7 As shown, an electronic device 700 provided in this embodiment of the invention includes: a processor 701, a memory 702 and a bus. The memory 702 stores a computer program that can run on the processor 701. When the electronic device 700 is running, the processor 701 and the memory 702 communicate through the bus. The processor 701 executes the computer program to implement the above-mentioned node-level configuration distribution method of the centralized service mesh.

[0120] Specifically, the memory 702 and processor 701 mentioned above can be general-purpose memory and processor, without any specific limitations here.

[0121] This invention also provides a node-level configuration distribution system for a centralized service mesh, such as... Figure 8 As shown, the system includes a centralized service mesh and node agents 802 deployed on nodes. The centralized service mesh includes a control plane 801 and a data plane 803 located on the DPU. The control plane 801 and the data plane 803 are respectively connected to the node agent 802.

[0122] After receiving the configuration acquisition request from the data plane 803, the node agent 802 sends a configuration distribution request to the control plane 801 with the target identity information containing the node identifier. The node agent 802 maintains the XDS configuration resource in real time by listening to changes in the pods on its node. The XDS configuration resource is used to record the XDS information of all pods on this node, and the XDS configuration resource has a specified field for recording the node identifier.

[0123] The control plane 801 is used to receive a configuration request and, based on the target identity information in the configuration request, return the target XDS configuration corresponding to the XDS configuration resource.

[0124] Node agent 802 is also used to forward the target XDS configuration to data plane 803 after receiving the target XDS configuration.

[0125] Furthermore, the control plane 801 is also used to monitor changes in XDS configuration resources through the K8s API server; when a change in XDS configuration resources is detected, the validity of the current XDS configuration resources is verified; after successful verification, the specified fields of the current XDS configuration resources are parsed to obtain the node identifier, so as to determine the node agent on which the current XDS configuration resources are applied; and the target XDS configuration is generated based on the XDS information of all pods recorded in the current XDS configuration resources.

[0126] The system provided in this embodiment has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0127] This invention also provides a computer-readable storage medium storing a computer program. When executed by a processor, this computer program performs the node-level configuration distribution method for the centralized service mesh described in the preceding method embodiments. The computer-readable storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), RAM, magnetic disks, or optical disks.

[0128] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0129] In all examples shown and described herein, any specific values ​​should be interpreted as merely exemplary and not as limitations; therefore, other examples of exemplary embodiments may have different values.

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

[0131] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0132] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0133] In addition, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0134] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for node-level configuration delivery of a centralized service mesh, characterized in that, This method is applied to node agents deployed on nodes using the DaemonSet approach. The node agents are connected to both the control plane of a centralized service mesh and the data plane located on the DPU. The node agents maintain XDS configuration resources in real-time by monitoring changes to the pods on their respective nodes. These XDS configuration resources record the XDS information of all pods on the node and include a designated field for recording node identifiers. Receive the configuration retrieval request sent by the data plane; The target identity information containing the node identifier is used to send a configuration request to the control plane, so that the control plane returns the target XDS configuration corresponding to the XDS configuration resource based on the target identity information in the configuration request. Receive the target XDS configuration and forward the target XDS configuration to the data plane.

2. The method of claim 1, wherein, The step of sending a configuration request to the control plane using the target identity information containing the node identifier includes: Obtain the initial identity information from the configuration acquisition request; Determine whether the initial identity information contains the node identifier; If the initial identity information does not contain the node identifier, the node identifier is added to the initial identity information of the configuration acquisition request to obtain a configuration request with the target identity information. The configuration request is sent to the control plane.

3. The method of claim 2, wherein, Before determining whether the initial identity information contains the node identifier, the method further includes: Send a node identifier retrieval request to the K8s API server in the control plane; Receive the node identifier returned by the K8s API server.

4. The method of claim 1, wherein, The method further includes: Monitor changes to pods on the local node in real time; When a pod change is detected, a pod information query request is sent to the K8s API server in the control plane; Receive the target pod information returned by the K8s API server; Update the XDS configuration resources based on the target pod information.

5. The method of claim 4, wherein, The step of updating the XDS configuration resources based on the target pod information includes: Based on the node identifier in the target pod information, determine whether the target pod that has changed is located on the node where the node agent is located; If the target pod is located on the node where the node agent is located, add the pod change event of the target pod to the processing queue; The pod change event is retrieved from the processing queue, and the target pod is processed and the XDS configuration resources are updated according to the event type of the pod change event.

6. The method of claim 5, wherein, The process of handling the target pod and updating the XDS configuration resources based on the event type of the pod change event includes: When the event type is a deletion event, the XDS information of the corresponding pod is deleted from the XDS configuration resource; When the event type is an add event or an update event, a target resource corresponding to the pod change event is created, and the corresponding pod XDS information in the XDS configuration resource is added or updated according to the target resource; wherein, the target resource includes listener, cluster, route and endpoint.

7. A node-level configuration delivery device of a centralized service mesh, characterized in that, An application is provided for a node agent deployed on nodes using the DaemonSet method. The node agent is connected to both the control plane of a centralized service mesh and the data plane located on the DPU. The node agent maintains XDS configuration resources in real time by monitoring changes to the pods on its node. These XDS configuration resources record XDS information for all pods on the node and include a designated field for recording node identifiers. The device includes: The first receiving module is used to receive the configuration acquisition request sent by the data plane; The first sending module is used to send a configuration request to the control plane with target identity information containing the node identifier, so that the control plane returns the target XDS configuration corresponding to the XDS configuration resource according to the target identity information in the configuration request. The second receiving module is used to receive the target XDS configuration; The second sending module is used to forward the target XDS configuration to the data plane.

8. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1-6. 9.A node-level configuration issuing system of a centralized service mesh, characterized in that, It includes a centralized service mesh and node agents deployed on nodes using the Daemonset method. The centralized service mesh includes a control plane and a data plane located on the DPU. The control plane and the data plane are respectively connected to the node agents. The node agent, upon receiving a configuration acquisition request from the data plane, sends a configuration request to the control plane with target identity information containing a node identifier. The node agent maintains XDS configuration resources in real time by monitoring changes in the pods on its node. These XDS configuration resources record the XDS information of all pods on the node and include a designated field for recording the node identifier. The control plane is used to receive the configuration request and, based on the target identity information in the configuration request, return the target XDS configuration corresponding to the XDS configuration resource. The node agent is also used to forward the target XDS configuration to the data plane after receiving the target XDS configuration.

10. The system of claim 9, wherein, The control plane is also used to monitor changes to the XDS configuration resources via the K8s API server; when a change to the XDS configuration resources is detected, the validity of the current XDS configuration resources is verified; after successful verification, the specified fields of the current XDS configuration resources are parsed to obtain the node identifier, so as to determine the node proxy that the current XDS configuration resources act on; and the target XDS configuration is generated based on the XDS information of all pods recorded in the current XDS configuration resources.

Images