ServiceMesh-based multi-cluster hot debugging method

Abstract

The invention discloses a multi-cluster hot debugging method based on Service Mesh, and belongs to the technical field of cloud native software development. Through a debugging instruction, a multi-cluster intelligent routing gateway establishes a unified and logically isolated debugging session and a virtual network environment for a developer terminal and a plurality of target Kubernetes clusters; the gateway dynamically allocates a local port for a debugging task from a global resource pool, and instructs a target cluster to create a Pod; the gateway serves as a center node, performs cross-cluster routing conflict detection, generates a globally consistent dynamic routing rule and issues the dynamic routing rule to a target cluster; and finally, forwarding the online traffic matched with the rule to an appointed port of a developer local machine through a proxy Pod and a gateway. Through a centralized intelligent coordination architecture, various conflicts in a multi-cluster environment are fundamentally avoided, and the debugging efficiency, stability and automation level are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a multi-cluster hot debugging method based on ServiceMesh. Background Technology

[0002] In the cloud-native era, microservice architecture has become the mainstream choice. By breaking down complex monolithic applications into a series of independently deployable microservices built around business logic, the flexibility and maintainability of the system are significantly improved. Container orchestration platforms, such as Kubernetes, solve problems related to application resource scheduling, automatic deployment, horizontal scaling, and fault self-healing, greatly improving the availability of the environment.

[0003] However, this advanced architecture also brings new challenges to traditional software development and debugging models. First, the Kubernetes cluster network is naturally isolated from the developer's local host network, preventing external devices from directly accessing services and Pods within the cluster. Traditional development models, such as testing by copying, deploying, and restarting services after modifying code locally, suffer from long feedback cycles and low efficiency. Especially in cloud-native environments, the complete CI / CD (Continuous Integration / Continuous Deployment) process involves multiple steps, including building images, uploading repositories, and updating and releasing, making the process lengthy and complex, severely hindering the speed of development iteration.

[0004] Furthermore, when multiple developers collaborate on the same application or interdependent services, sharing a single testing environment can easily lead to mutual interference. For example, frequent service restarts can reduce environment availability and impact overall development and testing efficiency. Existing solutions have addressed, to some extent, the network connectivity and integration issues between the local machine and a single Kubernetes cluster. These solutions create proxies within the cluster and forward online traffic to the local machine via tunnels or ports, combining this with service meshes like Istio to implement request header-based traffic routing, thus supporting hot debugging in a single-cluster environment.

[0005] However, as businesses expand, multi-regional, multi-environment, and multi-cluster deployments become the norm. At this point, the limitations of existing technical solutions become apparent. Simply mechanically replicating single-cluster debugging methods to multiple clusters leads to a series of deeper technical challenges, such as: potential CIDR (Concurrent Access Router) conflicts between different clusters; competition and preemption of limited local port resources when multiple debugging tasks run concurrently; and the ease with which cross-cluster routing strategies and application configurations can conflict in the absence of a globally unified coordination mechanism, resulting in debugging failures or unpredictable outcomes. Currently, existing solutions only address hot debugging in single-cluster environments. When facing multi-cluster, distributed microservice architectures, these methods have significant drawbacks: firstly, they require independent network configuration for each cluster, easily leading to debugging failures due to conflicts in network addresses, ports, and other resources; secondly, the lack of a unified coordination mechanism makes configuration complex and prone to interference when multiple developers collaborate on debugging across different clusters, severely impacting development efficiency. Therefore, there is an urgent need in this field for a novel hot debugging method that can effectively address the unique technical challenges of multi-cluster environments. Summary of the Invention

[0006] The purpose of this invention is to address the shortcomings of existing technologies by proposing a multi-cluster hot debugging method based on ServiceMesh.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: A multi-cluster hot debugging method based on ServiceMesh includes the following steps: S1. Establishing a session and registering a cluster context: A multi-cluster intelligent routing gateway receives a session establishment request from the developer's terminal, triggered in response to a debugging command, and creates a logically isolated session for this debugging based on the identity information of at least two target Kubernetes clusters contained in the request, while assigning a unique cluster identity identifier to each target Kubernetes cluster. S2. Create a virtual network environment: The multi-cluster intelligent routing gateway establishes an isolated virtual network namespace for the session, and maps the internal network addresses of the multiple target Kubernetes clusters to the virtual network namespace through network address translation technology, so as to achieve network address transparency for the developer terminal. S3. Schedule the proxy and allocate network resources: Receive a debugging request sent by the developer terminal for an application to be debugged, the debugging request containing the cluster identity identifier of the target cluster; In response to the request, the multi-cluster intelligent routing gateway dynamically allocates a unique local mapping port for the application to be debugged from a global port mapping pool maintained by it, and instructs the target cluster to create a proxy Pod with the cluster identity identifier attached. S4. Generate a globally consistent routing strategy: After the proxy Pod is successfully created, the multi-cluster intelligent routing gateway performs a cross-cluster configuration conflict detection and generates dynamic routing rules containing Istio VirtualService and DestinationRule based on the detection results. The dynamic routing rules are then distributed to the target cluster for application to take effect. S5. Forward debugging traffic: Online request traffic matching the dynamic routing rules is forwarded from the proxy Pod in the target cluster, via the multi-cluster intelligent routing gateway, and finally to the unique local mapping port dynamically allocated in step S3 on the developer terminal.

[0008] Furthermore, step S2 further includes: the multi-cluster unified DNS service built into the multi-cluster intelligent routing gateway automatically adds the cluster identity identifier corresponding to the target cluster as a DNS resolution suffix to the service domain name when resolving the service domain name, so as to resolve and distinguish services with the same name in different clusters.

[0009] Furthermore, before receiving the debugging request in step S3, the method further includes: the client tool deployed on the developer's terminal automatically extracts the application name and service port number of the application to be debugged by statically scanning the project configuration file of the application to be debugged, and includes the extracted application name and service port number in the debugging request.

[0010] Furthermore, the global port mapping pool in step S3 is isolated based on the session, ensuring that the local mapping port allocated to a session will not be occupied or accessed by other concurrent debugging sessions.

[0011] Furthermore, after step S3 and before step S5, the method further includes: establishing a reverse security tunnel between the proxy Pod and the multi-cluster intelligent routing gateway, wherein the debugging traffic in step S5 is encrypted and transmitted from the proxy Pod to the multi-cluster intelligent routing gateway via the reverse security tunnel. The tunnel establishment process includes: the multi-cluster intelligent routing gateway generating a temporary authentication token for the session and sending it to the proxy Pod; and the proxy Pod carrying the authentication token initiating a connection to the gateway, and establishing the tunnel only after successful authentication.

[0012] Further, in step S4, the cross-cluster configuration conflict detection specifically involves checking whether there are any active dynamic routing rules in other clusters associated with the session that have the same name as the application to be debugged; if so, it is determined to be a configuration conflict.

[0013] Furthermore, after determining that a configuration conflict has occurred, the multi-cluster intelligent routing gateway adopts a "last-in, first-out" strategy to resolve the conflict. Specifically, it generates new dynamic routing rules to atomically replace the previously effective dynamic routing rules that exist in other clusters, ensuring that only one debug route for the service with the same name is effective at any given time.

[0014] Furthermore, the VirtualService rule generated in step S4 includes an exact match for a specific HTTP request header in its traffic matching conditions. The request header carries a session ID generated by the multi-cluster intelligent routing gateway for the session. Furthermore, the dynamic routing rule generated in step S4 also includes a DestinationRule rule, which defines a first service subset and a second service subset for the application to be debugged. The first service subset matches the online application Pod, while the second service subset precisely matches the proxy Pod through a tag selector.

[0015] Furthermore, in step S3, a lightweight monitoring probe is embedded in the agent Pod, and the probe periodically reports its heartbeat, tunnel connection status and real-time traffic data to the multi-cluster intelligent routing gateway through the reverse security tunnel. Furthermore, the method also includes: when the multi-cluster intelligent routing gateway does not receive the heartbeat within a preset timeout period, it determines that the debugging session is abnormal and automatically issues an instruction to delete the dynamic routing rule and the proxy Pod associated with the session.

[0016] Furthermore, the method supports concurrent thermal debugging of multiple different applications to be debugged. The implementation method is as follows: for each debugging request of the application to be debugged, steps S3 and S4 are repeatedly executed. In this case, the multi-cluster intelligent routing gateway allocates an independent local mapping port from the global port mapping pool for each application to be debugged, and generates and manages multiple sets of parallel dynamic routing rules.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: By introducing a multi-cluster intelligent routing gateway as the central coordination node and creating a session-isolated virtual network namespace and a global port mapping pool, the network address and local port conflict issues in a multi-cluster environment are resolved, improving the stability and reliability of the debugging environment. The generation of routing policies and conflict detection decisions are centralized at the central gateway, enabling cross-cluster global configuration management and consistency verification. This avoids routing chaos and debugging failures caused by improper distributed configuration. Combined with intelligent parameter picking by the client and automated resource scheduling by the gateway, the manual configuration work of developers is minimized, simplifying the complex multi-cluster debugging process and significantly improving development and debugging efficiency.

[0018] Furthermore, through session isolation and intelligent routing redirection, the method can easily support complex parallel collaborative debugging by a single developer for multiple applications or by multiple developers for multiple services, and has good flexibility and horizontal scalability, thus adapting to the increasingly complex cloud-native IT architecture of modern enterprises. Attached Figure Description

[0019] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof.

[0020] Figure 1 A schematic diagram of a system architecture for a multi-cluster hot debugging method based on Service Mesh provided in an embodiment of the present invention; Figure 2 A detailed flowchart of a multi-cluster hot debugging method based on Service Gesh provided for embodiments of the present invention; Figure 3 This is a schematic diagram of the multi-cluster intelligent routing gateway functional module in an embodiment of the present invention; Figure 4 This is a logical diagram illustrating the cross-cluster configuration conflict detection and resolution in an embodiment of the present invention. Detailed Implementation

[0021] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0022] The hot debugging method provided in this invention is typically applicable to cloud-native computing environments based on mainstream service mesh frameworks (preferably Istio). For successful implementation of this invention, the relevant environment must meet the following prerequisites: The technical environment contains at least two geographically or logically independent Kubernetes clusters, which together constitute a multi-cluster environment to be debugged.

[0023] Each target Kubernetes cluster is in normal operation and has deployed a service mesh data plane proxy (such as Istio Sidecar) and pre-installed with the operator component described in this invention.

[0024] The environment deploys a multi-cluster intelligent routing gateway that is independent of each Kubernetes cluster and acts as a central coordinating node. This gateway is network reachable from the control plane of each target cluster and from the developer's terminal.

[0025] This embodiment introduces a centralized coordination architecture and combines it with the existing traffic management capabilities of the service mesh. It aims to systematically solve a series of technical bottlenecks faced by existing technologies when applied to multi-cluster hot debugging scenarios, such as network address conflicts, local port resource contention, inconsistent cross-cluster routing policies, and complex and cumbersome manual configuration. This provides an automated, efficient, and highly stable multi-cluster collaborative debugging solution.

[0026] Example 1 Reference Figure 1 The system architecture of this embodiment mainly consists of three parts: a developer terminal, a multi-cluster intelligent routing gateway, and at least two target Kubernetes clusters (shown as cluster a and cluster b in the diagram). The developer terminal is equipped with the client tool of this invention, which in this embodiment is a command-line tool named z-debug-ctl.

[0027] Reference Figure 2 The detailed execution flow of the method of the present invention is as follows: S1: The multi-cluster intelligent routing gateway receives a session establishment request from the developer's terminal, triggered in response to a debugging command. Based on the identity information of at least two target Kubernetes clusters contained in the request, it creates a globally unique, stateful session instance for this debugging session and generates a session ID (e.g., session-xyz). This session will serve as the core context throughout the debugging lifecycle, used to record state information such as associated clusters, port mappings, and routing rules. Subsequently, the multi-cluster intelligent routing gateway verifies the validity of cluster-a and cluster-b in the request and binds them to the newly created session-xyz. It also assigns them unique and easily identifiable cluster identities within this session (e.g., c1 and c2 respectively). This cluster-ID will serve as a precise index for all subsequent routing and management operations. S2: Create an isolated virtual network environment: A logically completely isolated network environment is created for session-xyz by a multi-cluster intelligent routing gateway. (See reference...) Figure 3 The virtual network management module inside the multi-cluster intelligent routing gateway uses the Linux kernel's network namespace or equivalent technology to create an independent virtual network space for the session. For clusters 30a (e.g., network segment 10.244.0.0 / 16) and 30b (also 10.244.0.0 / 16) that may have conflicting IP address ranges, the NAT module of the multi-cluster intelligent routing gateway will map their internal services to different private address ranges within this virtual space (e.g., 192.168.1.0 / 24 and 192.168.2.0 / 24), thereby achieving complete transparency and isolation of network addresses for the developer's terminal. Simultaneously, the DNS module 23 of the multi-cluster intelligent routing gateway automatically points the developer's terminal's DNS server to itself through client tools and uses the Cluster-ID as the resolution suffix for the service domain name (e.g., auth-service.c1.debug), enabling unambiguous access to services with the same name that may exist in the multi-cluster environment.

[0028] S3: Schedules proxy Pods and allocates network resources: When developers need to debug a billing-service application deployed in cluster-a, they execute the `z-debug-ctl mesh` command in its local source code directory. The client tool `z-debug-ctl` automatically performs intelligent parameter picking, automatically extracting the application name and port number (e.g., 8080) by scanning project files (such as `pom.xml` or `bootstrap.yml`), and packages it into a debug request along with the Cluster-ID (c1) and session ID in the current context, sending it to the multi-cluster intelligent routing gateway. The port management module of the multi-cluster intelligent routing gateway dynamically allocates a unique local port (e.g., 18080) for the debug task from its maintained, session-isolated global port pool, and records the mapping relationship from 18080 to 8080. This mechanism ensures that concurrent debug tasks will not cause local port conflicts. Subsequently, the multi-cluster intelligent routing gateway instructs the operator component in the target cluster c1 to create a proxy Pod and inject labels containing the session ID and Cluster-ID into it. To ensure connection security, the multi-cluster intelligent routing gateway generates a temporary authentication token for the session and securely distributes and injects this token into the agent Pod to be created. After the agent Pod starts, its built-in agent carries this authentication token and proactively establishes an encrypted and stable reverse tunnel (preferably WebSocket or gRPC) with the multi-cluster intelligent routing gateway. Only after the multi-cluster intelligent routing gateway verifies the token's validity will the tunnel connection be officially established for subsequent debugging traffic forwarding.

[0029] S4: Generate and distribute a globally consistent routing policy, which includes the following process: S401: Registration and debugging example: After the operator in cluster-a detects that the agent Pod has reached the Ready state, it reports its Pod IP and other status information to the routing policy center 25 of the multi-cluster intelligent routing gateway for registration.

[0030] S402: Reference Figure 4 Before generating a new rule, the routing policy center 25 queries the global routing table associated with session-xyz to check for any existing conflicting routing rules that also target billing-service (e.g., a debug task that previously pointed to the c2 cluster).

[0031] S403: Assuming a conflict is detected, the routing policy center 25 will apply a "Latter-wins" policy. It will first generate a directive to delete or disable the VirtualService rule that previously pointed to c2, and then generate a new rule for c1.

[0032] S404: Rule Issuance: The multi-cluster intelligent routing gateway issues these CRD resources defined in YAML text to the operator of cluster-a through a secure channel, which then applies and takes effect in cluster 30a.

[0033] S5: Forward debugging traffic: Once the preceding steps are completed, the debugging pipeline is fully established. When an online request carrying the correct HTTP header (z-debug-session: session-xyz) arrives at the billing-service, the IstioSidecar in cluster-a forwards the traffic to the proxy Pod according to the rules issued in S4. The proxy Pod sends the traffic data to the multi-cluster intelligent routing gateway through its reverse tunnel established with the multi-cluster intelligent routing gateway. The multi-cluster intelligent routing gateway, based on the session ID and application information, queries the port mapping relationship 18080 -> 8080, and ultimately forwards the traffic to the developer's terminal address 127.0.0.1:18080. The application instance running locally on port 8080 can then receive requests, perform breakpoint debugging, log viewing, real-time code modification, and hot reloading, thereby achieving efficient and conflict-free multi-cluster hot debugging.

[0034] To better understand the technical solution of this invention, the following description is provided in conjunction with application scenarios.

[0035] In an example scenario: Suppose a developer is developing an "Order Service" deployed in cluster-a (cluster ID c1). This service depends on a "User Service" deployed in cluster-b (cluster ID c2) and an "Inventory Service" deployed in cluster-a. To troubleshoot a failed order placement, the developer needs to debug the complex interactions between the "Order Service" and the other two services. Using the method of this invention, the developer only needs to execute one command, `z-debug-ctl mesh`, in the local "Order Service" code directory to establish a unified debugging session with the routing gateways of cluster-a and cluster-b. At this point, when a test order placement request flows through the online system to the "Order Service," the traffic is automatically forwarded to the developer's local machine. When the developer's local "Order Service" needs to call the "User Service" during processing, it can directly call it using the service name `user-service.c2.debug`. This call request will be seamlessly routed to the online instance in cluster-b by the multi-cluster intelligent routing gateway. Throughout the debugging process, the developer does not need to worry about the underlying complex cross-cluster network and can smoothly trace the complete business call chain, just like debugging at a breakpoint in a monolithic application.

[0036] In an example scenario: Suppose developer A is debugging a "frontend service" deployed locally in cluster-a, while developer B is debugging a "backend API service" deployed locally in cluster-b. A needs to debug a new version of the API that B is developing but has not yet deployed. Using the method of this invention, developers A and B only need to execute a single command, `z-debug-ctlmesh`, in their respective local service directories to establish their own independent debugging sessions (e.g., session-A and session-B) with the multi-cluster intelligent routing gateway. A can add two HTTP headers to its browser request via a plugin: `z-debug-session: session-A` and `z-debug-target-remap: backend-api-service=session-B`. When A's request reaches the multi-cluster intelligent routing gateway, the gateway recognizes session-A and directs the traffic to A's local frontend service. When A's frontend service calls the backend API, the gateway detects the `z-debug-target-remap` header and, according to this rule, intelligently redirects the request to developer B's debugging session, session-B, ultimately forwarding the traffic to B's local machine. This scenario fully demonstrates how the present invention enables complex multi-user, multi-service parallel collaborative debugging through session isolation and centralized intelligent routing.

[0037] To more intuitively demonstrate the significant advancements of this invention compared to traditional multi-cluster debugging methods, Table 1 provides a quantitative comparison based on typical debugging tasks: Table 1 Comparison items Traditional multi-cluster debugging methods Method of the present invention Remark Debugging environment preparation time 30 minutes or more Less than 1 minute Traditional methods require manually configuring VPNs and checking for network conflicts for each cluster. Network conflict risk High (CIDR requires manual troubleshooting, prone to errors) None (the gateway resolves this automatically via NAT and virtual networks). This invention avoids this problem through its architecture. Local port conflict risk High (Requires manual management and modification of application configuration) None (the gateway is dynamically allocated from the global port pool) This invention enables automated and conflict-free port allocation. Time spent switching the target cluster for debugging Minutes or less (requires disconnecting the old VPN, connecting to the new VPN, and modifying the routing) Time-efficient (simply execute a single mesh command) This greatly improves the efficiency of switching and debugging between multiple clusters. Configuration consistency guarantee Low (relies on manual operation, which can easily lead to inconsistent configurations across clusters due to negligence). High (routing policies are uniformly generated and distributed by the gateway) This ensures the consistency and accuracy of the global configuration. Multi-person collaborative debugging capability Extremely weak (easily interferes with each other, requires the construction of multiple complete environments, and is costly). Strong (easily achieved through session isolation and intelligent routing) This greatly reduces the complexity and resource costs of collaborative debugging. The multi-cluster intelligent routing gateway serves as the central hub of this invention, integrating multiple collaborative modules such as virtual network management, NAT, unified DNS, port pool management, and a routing policy center. This centralized design enables the intelligent scheduling and management of previously scattered and difficult-to-coordinate multi-cluster debugging tasks on a unified node with a global perspective.

[0038] This invention uses a Cluster-ID mechanism and session ID to assign a unique and traceable tag to each debugging request and resource, forming the basis for identity and addressing in a multi-cluster environment. The gateway's routing policy center relies on these tags to achieve cross-cluster configuration conflict detection and precise traffic control.

[0039] All requests to the multi-cluster intelligent routing gateway undergo rigorous authentication and authorization. Session-based isolation mechanisms ensure that resources and traffic do not interfere with each other between different debugging tasks. The agent built into the proxy Pod periodically reports heartbeats to the multi-cluster intelligent routing gateway. When the multi-cluster intelligent routing gateway detects anomalies (such as tunnel interruption), it automatically cleans up its issued routing rules to prevent online traffic from being forwarded to invalid targets and forming a "traffic black hole," thereby ensuring the stability of online services.

[0040] In one specific implementation, to ensure the stability of online services when debugging anomalies, a heartbeat-based automatic resource reclamation mechanism is also included, specifically: The status information reported in S401 includes heartbeats. When the multi-cluster intelligent routing gateway does not receive a valid heartbeat from the proxy Pod within a preset timeout period (e.g., 60 seconds), it determines that the debugging session is abnormal and automatically triggers a cleanup process. This involves sending a command to the target cluster to forcibly delete the VirtualService, DestinationRule resources, and proxy Pods associated with the session, thereby preventing online traffic from being forwarded to invalid targets and creating a "traffic black hole." Those skilled in the art should understand that the above embodiments are merely examples, and various modifications and variations can be made without departing from the spirit and scope of the invention. For example, in addition to the "last-come, first-served" conflict resolution strategy, a priority-based strategy can also be used; the specific implementation technology of the reverse tunnel can be WebSocket, gRPC, or QUIC, etc. All these variations should fall within the protection scope of the present invention.

Claims

1. A multi-cluster hot debugging method based on ServiceMesh, characterized in that, Includes the following steps: S1. A multi-cluster intelligent routing gateway receives a session establishment request from the developer terminal, triggered in response to a debugging command, and creates a logically isolated session for this debugging based on the identity information of at least two target Kubernetes clusters contained in the request, while assigning a unique cluster identity identifier to each target Kubernetes cluster. S2. The multi-cluster intelligent routing gateway establishes an isolated virtual network namespace for the session, and maps the internal network addresses of multiple target Kubernetes clusters to the virtual network namespace through network address translation technology, so as to make the network address of the developer terminal transparent. S3. Receive a debugging request sent by the developer terminal for the application to be debugged, wherein the debugging request includes the cluster identity identifier of the target cluster; In response to the request, the multi-cluster intelligent routing gateway dynamically allocates a unique local mapping port for the application to be debugged from its maintained global port mapping pool, and instructs the target cluster to create a proxy Pod with the cluster identity tag attached. S4. After the proxy Pod is successfully created, the multi-cluster intelligent routing gateway performs cross-cluster configuration conflict detection and generates dynamic routing rules containing Istio VirtualService and DestinationRule based on the detection results. Then, the dynamic routing rules are sent to the target cluster for application to take effect. S5. Online request traffic matching the dynamic routing rules is forwarded from the proxy Pod in the target cluster, via the multi-cluster intelligent routing gateway, and finally to the unique local mapping port dynamically allocated in step S3 on the developer terminal.

2. The multi-cluster hot debugging method based on ServiceMesh according to claim 1, characterized in that, Step S2 further includes: the multi-cluster unified DNS service built into the multi-cluster intelligent routing gateway automatically adds the cluster identity identifier corresponding to the target cluster as a DNS resolution suffix to the service domain name when resolving the service domain name, so as to resolve and distinguish services with the same name in different clusters.

3. The multi-cluster hot debugging method based on ServiceMesh according to claim 2, characterized in that, Before receiving the debugging request in step S3, the method further includes: the client tool deployed on the developer's terminal automatically extracts the application name and service port number of the application to be debugged by statically scanning the project configuration file of the application to be debugged, and includes the extracted application name and service port number in the debugging request.

4. The multi-cluster hot debugging method based on ServiceMesh according to claim 3, characterized in that, The global port mapping pool in step S3 is isolated based on the session, ensuring that the local mapping port allocated to a session will not be occupied or accessed by other concurrent debugging sessions.

5. The multi-cluster hot debugging method based on ServiceMesh according to claim 4, characterized in that, After step S3 and before step S5, the method further includes: establishing a reverse security tunnel between the proxy Pod and the multi-cluster intelligent routing gateway, wherein the debugging traffic in step S5 is encrypted and transmitted from the proxy Pod to the multi-cluster intelligent routing gateway via the reverse security tunnel. The tunnel establishment process includes: the multi-cluster intelligent routing gateway generating a temporary authentication token for the session and sending it to the proxy Pod; and the proxy Pod carrying the authentication token initiating a connection to the gateway, and establishing the tunnel only after successful authentication.

6. The multi-cluster hot debugging method based on ServiceMesh according to claim 2, characterized in that, In step S4, the cross-cluster configuration conflict detection specifically involves checking whether there are any active dynamic routing rules in other clusters associated with the session that have the same name as the application to be debugged. If it exists, it is determined to be a configuration conflict.

7. The multi-cluster hot debugging method based on ServiceMesh according to claim 6, characterized in that, After determining a configuration conflict, the multi-cluster intelligent routing gateway resolves it using a last-to-first strategy, specifically: Generate new dynamic routing rules to atomically replace previously active dynamic routing rules that exist in other clusters, ensuring that at any given time only one debug route is active for the service with the same name.

8. The multi-cluster hot debugging method based on ServiceMesh according to claim 7, characterized in that, The VirtualService rule generated in step S4 includes a precise match for a specific HTTP request header in its traffic matching conditions. The request header carries a session ID generated by the multi-cluster intelligent routing gateway for the session. Furthermore, the dynamic routing rules generated in step S4 also include DestinationRule rules, which define a first service subset and a second service subset for the application to be debugged. The first service subset matches the online application Pod, while the second service subset precisely matches the proxy Pod through a tag selector.

9. The multi-cluster hot debugging method based on ServiceMesh according to claim 5, characterized in that, In step S3, a lightweight monitoring probe is embedded in the agent Pod, and the probe periodically reports its heartbeat, tunnel connection status and real-time traffic data to the multi-cluster intelligent routing gateway through the reverse security tunnel. Furthermore, the method also includes: when the multi-cluster intelligent routing gateway does not receive the heartbeat within a preset timeout period, it determines that the debugging session is abnormal and automatically issues an instruction to delete the dynamic routing rule and the proxy Pod associated with the session.

10. The multi-cluster hot debugging method based on ServiceMesh according to claim 1, characterized in that, The method supports concurrent thermal debugging of multiple different applications to be debugged. The implementation is as follows: for each debugging request of the application to be debugged, steps S3 and S4 are repeatedly executed. The multi-cluster intelligent routing gateway allocates an independent local mapping port from the global port mapping pool for each application to be debugged, and generates and manages multiple sets of parallel dynamic routing rules.

Images