A multi-cluster hot debugging method based on ServiceMesh

Abstract

The application discloses a kind of multi-cluster hot debugging methods based on Service Mesh, belong to cloud native software development technical field.The unified, logical isolated debugging session and virtual network environment of multiple target Kubernetes clusters are established for developer terminal by the intelligent routing gateway of multiple clusters by a debugging instruction;Local port is dynamically allocated for debugging task from global resource pool by the gateway, and target cluster is instructed to create proxy Pod;Gateway serves as the central node, performs cross-cluster routing conflict detection, and generates globally consistent dynamic routing rules and issues to target cluster;Finally, online traffic matching rules is forwarded to the specified port of developer's local machine via proxy Pod and gateway.Through the centralized intelligent coordination architecture, various conflicts under the multi-cluster environment are fundamentally avoided, and the debugging efficiency, stability and automation level are significantly improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer technology, and particularly relates to a multi-cluster hot debugging method based on ServiceMesh. BACKGROUND

[0002] Under the background of cloud-native era, microservice architecture has become the mainstream choice. By splitting complex monolithic applications into a series of independently deployable microservices built around business, the flexibility and maintainability of the system are significantly improved. Container orchestration platforms represented by Kubernetes solve the problems of application resource scheduling, automatic deployment, horizontal expansion and fault self-healing, greatly improving the availability of the environment.

[0003] However, this advanced architecture also brings new challenges to the traditional software development and debugging mode. First, the Kubernetes cluster network is naturally isolated from the local host network of the developer, and external devices cannot directly access the services and Pods inside the cluster. Traditional development modes, such as modifying code locally and then testing by copying, deploying, and restarting services, have long feedback cycles and low efficiency. Especially in the cloud-native environment, the complete CI / CD (Continuous Integration / Continuous Deployment) process involves multiple steps such as building images, uploading repositories, and updating releases, which is complex and time-consuming, seriously restricting the speed of development iteration.

[0004] In addition, when multiple developers collaborate on the same application or interdependent services, sharing a test environment can easily interfere with each other, for example, frequent service restarts can reduce the availability of the environment and affect the overall development and testing efficiency. Some existing solutions solve the problem of network interconnection and joint debugging between local and single Kubernetes cluster to some extent. These solutions create proxies in the cluster and tunnel or port forward online traffic to the local, combined with service mesh such as Istio to implement request header-based traffic routing, thereby supporting hot debugging in a single-cluster environment.

[0005] However, as the business scale of enterprises expands, multi-region, multi-environment, and multi-cluster deployment becomes the norm. At this time, the limitations of the existing technical solutions become apparent. Simply mechanically replicating the debugging method for a single cluster to multiple clusters can cause a series of deeper technical problems, such as: network address segment (CIDR) conflict problems that may exist between different clusters; competition and preemption of local limited port resources of developers when multiple debugging tasks are concurrent; and in the absence of a global unified coordination mechanism, cross-cluster routing strategies and application configurations are prone to conflict, leading to debugging failure or unpredictable results. However, the existing technology disclosed in the prior art can only solve the hot debugging problem in a single cluster environment. In the face of multi-cluster, distributed micro-service architecture, the above method has significant defects: first, independent network configuration is required for each cluster, which is prone to debugging failure due to network address, port, and other resource conflicts; second, there is a lack of unified coordination mechanism, and multiple developers collaborate in debugging between different clusters, which is complex and prone to mutual interference, seriously affecting development efficiency. Therefore, there is an urgent need in the field for a new hot debugging method that can effectively solve the unique technical challenges in the above multi-cluster environment. SUMMARY

[0006] The purpose of the present application is to solve the defects in the prior art and to provide a multi-cluster hot debugging method based on ServiceMesh.

[0007] To achieve the above purpose, the present application adopts the following technical solutions:

[0008] A multi-cluster hot debugging method based on ServiceMesh, comprising the following steps:

[0009] S1, establishing a session and registering a cluster context: a multi-cluster intelligent routing gateway receives a session establishment request from a developer terminal triggered in response to a debugging instruction, and creates a logically isolated session for this debugging according to the identity information of at least two target Kubernetes clusters contained in the request, and assigns a unique cluster identity to each target Kubernetes cluster;

[0010] S2, creating 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 to realize network address transparency of the developer terminal;

[0011] S3, scheduling an agent and allocating network resources: receiving a debugging request sent by the developer terminal for a to-be-debugged application, the debugging request containing the cluster identity of a target cluster; in response to the request, dynamically allocating a unique local mapping port for the to-be-debugged application from a global port mapping pool maintained by the multi-cluster intelligent routing gateway, and instructing the target cluster to create an agent Pod attached with a label of the cluster identity;

[0012] S4, generating a globally consistent routing strategy: after the creation of the agent Pod, performing a cross-cluster configuration conflict detection by the multi-cluster intelligent routing gateway, and generating dynamic routing rules including Istio VirtualService and DestinationRule based on the detection result, and then issuing the dynamic routing rules to the target cluster for application and validation;

[0013] S5, forwarding debugging traffic: forwarding online request traffic matching the dynamic routing rules from the agent Pod in the target cluster to the unique local mapping port of the developer terminal dynamically allocated in step S3 via the multi-cluster intelligent routing gateway.

[0014] Further, the step S2 further comprises: when resolving a service domain name, automatically adding the cluster identity corresponding to the target cluster as a DNS resolution suffix after the service domain name by a multi-cluster unified DNS service built in the multi-cluster intelligent routing gateway, to resolve and distinguish services with the same name in different clusters.

[0015] Further, before receiving the debugging request in step S3, it further comprises: automatically extracting the application name and service port number of the to-be-debugged application by a client tool deployed on the developer terminal through static scanning of the project configuration file of the to-be-debugged application, and including the extracted application name and service port number in the debugging request.

[0016] Further, the global port mapping pool in step S3 is isolated based on the session, ensuring that the local mapping port allocated to one session cannot be occupied and accessed by other concurrent debugging sessions.

[0017] Further, after step S3 and before step S5, it further comprises: establishing a reverse secure tunnel between the agent Pod and the multi-cluster intelligent routing gateway, and the debugging traffic in step S5 is transmitted from the agent Pod to the multi-cluster intelligent routing gateway via the reverse secure tunnel;

[0018] The tunnel establishment process includes: generating, by the multi-cluster intelligent routing gateway, a temporary authentication token for the session and issuing the token to the proxy Pod; and initiating, by the proxy Pod, connection to the gateway while carrying the authentication token, and establishing the tunnel only after authentication is passed.

[0019] Further, in the step S4, the cross-cluster configuration conflict detection is specifically checking whether there is an effective dynamic routing rule for the service with the same name as the current application to be debugged in other clusters associated with the session; if so, it is determined as a configuration conflict.

[0020] Further, after determining that there is a configuration conflict, the multi-cluster intelligent routing gateway adopts a "last-to-first" based strategy to solve the problem, specifically: generating a new dynamic routing rule to replace the previously existing effective dynamic routing rule in other clusters atomically, ensuring that only one debugging route for the same service is effective at any moment.

[0021] Further, the VirtualService rule generated in the step S4 contains an exact match for a specific HTTP request header in its traffic matching condition, and the request header carries a session ID generated by the multi-cluster intelligent routing gateway for the session;

[0022] Also, the dynamic routing rule generated in the step S4 further 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 application Pod online, and the second service subset exactly matches the proxy Pod through a label selector.

[0023] Further, in the step S3, a lightweight monitoring probe is embedded in the proxy Pod, and the probe periodically reports its heartbeat, tunnel connection state and real-time traffic data to the multi-cluster intelligent routing gateway through the reverse secure tunnel;

[0024] Also, the method further includes: determining that the debugging session is abnormal when the multi-cluster intelligent routing gateway does not receive the heartbeat within a preset timeout period, and automatically issuing an instruction to delete the dynamic routing rule and the proxy Pod associated with the session.

[0025] Further, the method supports concurrent hot debugging of multiple different applications to be debugged, and the implementation is: repeating steps S3 and S4 for each debugging request of an application to be debugged, wherein the multi-cluster intelligent routing gateway allocates a local mapping port independent of each other from the global port mapping pool for each application to be debugged, and generates and manages multiple sets of parallel dynamic routing rules.

[0026] Compared with the prior art, the application has the beneficial effects that:

[0027] By introducing a multi-cluster intelligent routing gateway as a central coordination node and creating a session-isolated virtual network namespace and a global port mapping pool, the network address and local port conflict problem in a multi-cluster environment is solved, the stability and reliability of the debugging environment are improved, the generation of the routing strategy and the conflict detection decision-making power are collected to the central gateway, so that global configuration management and consistency checking across clusters can be realized, and routing chaos and debugging failure caused by improper distributed configuration are avoided. Combined with intelligent parameter pickup of the client and automatic resource scheduling of the gateway, the manual configuration work of the developer is minimized, the complex multi-cluster debugging process is simplified, and the development and debugging efficiency is significantly improved.

[0028] In addition, the method can easily support complex parallel collaborative debugging of a single developer for multiple applications or multiple developers for multiple services through session isolation and intelligent routing redirection, has good flexibility and horizontal expansion capability, and thus can adapt to the increasingly complex cloud-native IT architecture of modern enterprises. BRIEF DESCRIPTION OF DRAWINGS

[0029] The accompanying drawings are included to provide a further understanding of the application, and constitute a part of the specification, illustrate the application together with the embodiments of the application, and do not constitute a limitation on the application.

[0030] Figure 1 A system architecture schematic diagram of a multi-cluster hot debugging method based on Service Mesh provided by the embodiment of the application is shown in the figure.

[0031] Figure 2 A detailed flowchart of a multi-cluster hot debugging method based on Service Mesh provided by the embodiment of the application is shown in the figure.

[0032] Figure 3 A schematic diagram of a multi-cluster intelligent routing gateway function module in the embodiment of the application is shown in the figure.

[0033] Figure 4 A logic schematic diagram of cross-cluster configuration conflict detection and resolution in the embodiment of the application is shown in the figure. DETAILED DESCRIPTION

[0034] The technical solutions in the embodiments of the application will be described clearly and completely below with reference to the accompanying drawings of the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, not all the embodiments of the application.

[0035] The heat debugging method provided by the embodiment of the application is applicable to a typical technical scenario of a cloud native computing environment based on a mainstream service mesh (Service Mesh) framework (preferably, Istio). To successfully implement the method of the application, the related environment needs to meet the following prerequisite conditions:

[0036] There are at least two Kubernetes clusters that are independent of each other in geographical position or logic in the technical environment, and these clusters collectively constitute a multi-cluster environment to be debugged.

[0037] Each target Kubernetes cluster is in a normal running state, has deployed a data plane proxy (such as an Istio Sidecar) of a service mesh, and is pre-installed with the operator component described in the application.

[0038] A multi-cluster intelligent routing gateway that is independent of each Kubernetes cluster and serves as a central coordination node is deployed in the environment, and the gateway is network-reachable between the control plane of each target cluster and a developer terminal.

[0039] The embodiment introduces a centralized coordination architecture and combines the existing traffic management capabilities of a service mesh, aiming to systematically solve a series of technical bottlenecks such as network address conflicts, local port resource competition, inconsistent cross-cluster routing strategies, and complex and tedious manual configuration when the existing technology is applied to a multi-cluster heat debugging scenario, thereby providing an automated, efficient, and stable multi-cluster collaborative debugging solution.

[0040] Embodiment 1

[0041] With reference to Figure 1 The system architecture of the embodiment mainly consists of three parts: a developer terminal, a multi-cluster intelligent routing gateway, and at least two target Kubernetes clusters (illustrated as cluster a and cluster b). The client tool of the application, which is a command line tool named z-debug-ctl in this embodiment, is deployed on the developer terminal.

[0042] With reference to Figure 2 The detailed execution process of the method of the application is as follows:

[0043] S1: Receive a session establishment request from a developer terminal in response to a debugging instruction by the multi-cluster intelligent routing gateway, and create a globally unique, stateful session instance for this debugging according to the identity information of at least two target Kubernetes clusters contained in the request, and generate a session ID (for example, session-xyz). This session will serve as the core context during the lifetime of this debugging, and will be used to record state information such as associated clusters, port mappings, routing rules, etc. Subsequently, the multi-cluster intelligent routing gateway will verify the validity of cluster-a and cluster-b in the request, and bind them to the newly created session session-xyz, and assign them unique and easily identifiable cluster identity Cluster-ID (for example, c1 and c2 respectively) within this session, which will serve as the precise index for all subsequent routing and management operations.

[0044] S2: Create an isolated virtual network environment:

[0045] Create a logically completely isolated network environment for the session session-xyz by the multi-cluster intelligent routing gateway. Referring to Figure 3 , the virtual network management module inside the multi-cluster intelligent routing gateway creates an independent virtual network space for this session using the Linux kernel's Network Namespace or equivalent technology. For the backend clusters 30a (with a network segment of 10.244.0.0 / 16) and 30b (also with a network segment of 10.244.0.0 / 16) that may have IP address segment conflicts, the NAT module of the multi-cluster intelligent routing gateway will map their internal services to different private address segments (for example, 192.168.1.0 / 24 and 192.168.2.0 / 24) in this virtual space, thereby achieving complete transparency and isolation of network addresses for the developer terminal. At the same time, the DNS module 23 of the multi-cluster intelligent routing gateway automatically points the DNS server of the developer terminal to itself through the client tool, and uses Cluster-ID as the resolution suffix of the service domain name (for example, auth-service.c1.debug), thereby achieving unambiguous access to the same-named services in the multi-cluster environment.

[0046] S3: Schedule proxy Pods and allocate network resources:

[0047] When a developer needs to debug the billing-service application deployed in cluster-a, he executes the z-debug-ctl mesh command under his local source code directory. The client tool z-debug-ctl automatically performs intelligent parameter picking, automatically extracts the application name and port number (such as 8080) by scanning the project file (such as pom.xml or bootstrap.yml), and packs them into a debugging request together with the Cluster-ID (c1) and session ID in the current context, and sends them to the multi-cluster intelligent routing gateway. The port management module of the multi-cluster intelligent routing gateway dynamically allocates a unique local port (such as 18080) for this debugging task from the global port pool it maintains based on session isolation, and records the mapping relationship of 18080 -> 8080. This mechanism ensures that concurrent debugging 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. To ensure connection security, the multi-cluster intelligent routing gateway generates a temporary authentication token (Token) for this session at this time and issues the token to the proxy Pod to be created and injects it into the proxy Pod. After the proxy Pod starts, its built-in agent carries this authentication token and actively establishes an encrypted and stable reverse tunnel (preferably WebSocket or gRPC) with the multi-cluster intelligent routing gateway, and only after the multi-cluster intelligent routing gateway verifies the validity of the token does it establish the tunnel connection for subsequent debugging traffic forwarding.

[0048] S4: Generate and issue a globally consistent routing strategy, which includes the following processes:

[0049] S401: Register the debugging instance: After the operator in cluster-a detects that the proxy Pod reaches the Ready state, it reports the Pod IP and other status information to the routing strategy center 25 of the multi-cluster intelligent routing gateway for registration.

[0050] S402: Refer to Figure 4 Before generating a new rule, the routing strategy center 25 queries the global routing table associated with the session session-xyz to check whether there is an effective conflict routing rule (for example, a previous debugging task pointing to the c2 cluster) that also targets the billing-service.

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

[0052] S404: Rule delivery: The multi-cluster intelligent routing gateway delivers these CRD resources defined in YAML text to the operator of cluster-a through a secure channel, and the operator applies them in cluster 30a to take effect.

[0053] S5: Forward debug traffic:

[0054] After the current sequence of steps is completed, the debug link is fully established. When an online request carrying the correct HTTP header (z-debug-session: session-xyz) arrives at billing-service, the IstioSidecar in cluster-a will forward the traffic to the proxy Pod according to the rule issued in S4. The proxy Pod sends traffic data to the multi-cluster intelligent routing gateway through the reverse tunnel established with the multi-cluster intelligent routing gateway. The multi-cluster intelligent routing gateway queries the port mapping relationship 18080 -> 8080 according to the session ID and application information, and finally forwards the traffic to the 127.0.0.1:18080 address of the developer's terminal. The application instance running locally on the 8080 port of the developer can receive the request and perform breakpoint debugging, log viewing, real-time code modification, and hot loading, thereby achieving efficient and conflict-free multi-cluster hot debugging.

[0055] In order to better understand the technical solutions of the present application, the following will be further described in conjunction with application scenarios.

[0056] In an example scenario:

[0057] Suppose a developer is developing an "order service" deployed in cluster-a (cluster ID c1), which depends on a "user service" deployed in cluster-b (cluster ID c2) and an "inventory service" deployed in cluster-a. To troubleshoot a failure of a single order, the developer needs to debug the complex interaction of the "order service" with the other two services. By using the method of the application, the developer only needs to execute an instruction z-debug-ctl mesh in the local "order service" code directory to establish a unified debugging session with the routing gateway of cluster-a and cluster-b. At this time, when the test order request flows through the online system to the "order service", the traffic will be automatically forwarded to the developer's local machine. The "order service" on the developer's local machine needs to call the "user service" during processing, and can directly call the service name user-service.c2.debug. The call request will be routed to the online instance in cluster-b by the multi-cluster intelligent routing gateway without awareness. During the entire debugging process, the developer does not need to care about the complex cross-cluster network, and can smoothly track the complete business call chain like breakpoint debugging in a monolithic application.

[0058] In an example scenario:

[0059] Suppose developer A is debugging a "front-end service" deployed in cluster-a locally, and developer B is debugging a "back-end API service" deployed in cluster-b locally. A needs to co-debug the new version of API developed by B, which has not been deployed yet. By using the method of the application, developers A and B only need to execute an instruction z-debug-ctl mesh in the service directory of their respective local machines to establish their own independent debugging sessions (for example, session-A and session-B). A can add two HTTP headers in its browser request through a plug-in: 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 front-end service. When A's front-end service calls the back-end API, the gateway detects the z-debug-target-remap header and intelligently redirects the request to the debugging session session-B of developer B according to the rule, and finally the traffic is forwarded to B's local machine. This scenario fully demonstrates that the application realizes complex multi-person, multi-service parallel collaborative debugging through session isolation and centralized intelligent routing.

[0060] To show the significant progress of the present application relative to the traditional multi-cluster debugging method more intuitively, Table 1 provides a quantitative comparison based on a typical debugging task:

[0061] Table 1

[0062] Comparison item Traditional multi-cluster debugging method Invention method Note Debugging environment preparation time More than 30 minutes Less than 1 minute The traditional method needs to manually configure VPN for each cluster and check network conflicts. Network conflict risk High (manual CIDR checking is prone to errors) None (gateway automatically solves through NAT and virtual network) The invention avoids this problem from the architecture. Local port conflict risk High (manual management and application configuration modification are required) None (gateway dynamically allocates from a global port pool) The invention realizes automatic and conflict-free allocation of ports. Switching debugging target cluster time-consuming Minutes (need to disconnect old VPN, connect new VPN, and modify route) Seconds (execute a mesh instruction) Greatly improves the efficiency of switching between multiple clusters for debugging. Configuration consistency guarantee Low (dependent on manual operation, prone to inconsistencies due to negligence) High (global routing strategy is uniformly generated and issued by the gateway) Ensures consistency and accuracy of global configuration. Multi-person collaborative debugging capability Very weak (prone to interference, requires building multiple complete environments, high cost) Strong (easily achieved through session isolation and intelligent routing) Greatly reduces the complexity and resource cost of collaborative debugging.

[0063] The multi-cluster intelligent routing gateway, as the hub of the present application, integrates multiple modules that work together, such as virtual network management, NAT, unified DNS, port pool management, and routing policy center, inside. This centralized design enables the originally scattered and difficult-to-coordinate multi-cluster debugging tasks to be intelligently scheduled and managed on a unified node with a global perspective.

[0064] The present application labels each debugging request and resource with a unique and traceable label through the Cluster-ID mechanism and session ID, forming the basis of identity and addressing in a multi-cluster environment. The routing policy center of the gateway relies on these labels to achieve cross-cluster configuration conflict detection and precise traffic control.

[0065] All requests sent to the multi-cluster intelligent routing gateway are strictly authenticated. The session-based isolation mechanism ensures that resources and traffic between different debugging tasks do not interfere with each other. The agent built-in agent in the proxy Pod periodically reports heartbeats to the multi-cluster intelligent routing gateway. When the multi-cluster intelligent routing gateway detects an anomaly (such as tunnel interruption), it will automatically clean up the routing rules it has issued, avoiding the formation of a "traffic black hole" by forwarding online traffic to invalid targets, thereby ensuring the stability of online services.

[0066] In a specific implementation, to ensure the stability of online services in the event of debugging exceptions, a heartbeat-based resource automatic recovery mechanism is also included, which specifically includes:

[0067] The status information reported in S401 contains 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, i.e., issuing instructions to the target cluster to forcibly delete the VirtualService, DestinationRule resources associated with the session, and the proxy Pod, thereby avoiding the formation of a "traffic black hole" by forwarding online traffic to invalid targets.

[0068] Those skilled in the art should understand that the above embodiments are only examples, and various modifications and variations can be made without departing from the spirit and scope of the present application. For example, in addition to "last one wins", the conflict resolution strategy can also be a priority-based strategy; the specific implementation technology of the reverse tunnel can be WebSocket, gRPC, or QUIC, etc. These variations should all fall within the protection scope of the present application.

Claims

1. A method for hot debugging of multi-cluster based on ServiceMesh, characterized in that, The method comprises the following steps: S1, receiving, by a multi-cluster intelligent routing gateway, a session establishment request triggered in response to a debugging instruction from a developer terminal, and creating a logically isolated session for this debugging according to the identity information of at least two target Kubernetes clusters contained in the request, and assigning a unique cluster identity to each of the target Kubernetes clusters; 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, for transparentization of the network address of the developer terminal; S3, receiving a debugging request for an application to be debugged sent by the developer terminal, the debugging request containing the cluster identity of the target cluster; In response to the request, the multi-cluster intelligent routing gateway dynamically allocs a unique local mapping port for the application to be debugged from a global port mapping pool maintained by the multi-cluster intelligent routing gateway, and instructs the target cluster to create a proxy Pod labeled with the cluster identity; S4, after the creation of the proxy Pod, 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 result, and then issues the dynamic routing rules to the target cluster for application; S5, online request traffic matching the dynamic routing rules is finally forwarded to the unique local mapping port of the developer terminal in step S3 from the proxy Pod in the target cluster via the multi-cluster intelligent routing gateway.

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

3. The ServiceMesh-based multi-cluster hot debugging method according to claim 2, characterized in that, Before receiving the debugging request in step S3, it further comprises: a client tool deployed on the developer 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 ServiceMesh-based multi-cluster hot debugging method 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 cannot be occupied and accessed by other concurrent debugging sessions.

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

6. The ServiceMesh-based multi-cluster hot debugging method according to claim 2, characterized in that, In the step S4, the cross-cluster configuration conflict detection is specifically: checking whether there is an effective dynamic routing rule in other clusters associated with the session and for a service with the same name as the current application to be debugged; If so, it is determined that there is a configuration conflict.

7. The ServiceMesh-based multi-cluster hot debugging method according to claim 6, characterized in that, After determining that there is a configuration conflict, the multi-cluster intelligent routing gateway adopts a strategy based on the last-to-first priority to solve the problem, specifically: A new dynamic routing rule is generated to replace the previously existing effective dynamic routing rule in other clusters in an atomic manner, ensuring that only one debugging route for the service with the same name is effective at any moment.

8. The method of claim 7, wherein the ServiceMesh-based multi-cluster hot debugging method is characterized in that, The VirtualService rule generated in the step S4 contains an exact match for a specific HTTP request header in the traffic matching condition, and the request header carries a session ID generated by the multi-cluster intelligent routing gateway for the session; In addition, the dynamic routing rule generated in the 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 application Pod on the line, and the second service subset exactly matches the proxy Pod through a label selector.

9. The method of claim 5, wherein the ServiceMesh-based multi-cluster hot debugging method is characterized in that, In the step S3, a lightweight monitoring probe is embedded in the proxy Pod, and the probe periodically reports its heartbeat, tunnel connection state and real-time traffic data to the multi-cluster intelligent routing gateway through the reverse secure tunnel; In addition, the method further includes: determining that the debugging session is abnormal when the multi-cluster intelligent routing gateway does not receive the heartbeat within a preset timeout period, and automatically issuing an instruction to delete the dynamic routing rule and the proxy Pod associated with the session.

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

Images