A multi-cluster, multi-strategy traffic scheduling system

Abstract

This invention belongs to the field of multi-cluster network scheduling technology, specifically a multi-cluster, multi-policy traffic scheduling system. Its features include a K8S cluster, cluster A, and cluster B. The K8S cluster includes the `traefik` command, with its output connected to the inputs of the `Nginx-001` and `Nginx-002` commands. Cluster A and cluster B are configured within the K8S cluster. Cluster A and cluster B each include one `kong` command and four `pod` commands, with the output of the `kong` command connected to the input of the `pod` commands. Through the design of the K8S, A, and B clusters, this invention allows for traffic splitting and switching between clusters A and B using `nginx` commands. Cluster A is the latest version cluster, while cluster B is a stable version cluster. During normal operation, the version difference between cluster A and cluster B does not exceed one week. If cluster A detects an application failure due to a release issue, it will quickly switch all traffic to cluster B for rapid recovery. The technical team can still locate, analyze, and re-release the problem by accessing cluster A.

Description

Technical Field

[0001] This invention belongs to the field of multi-cluster network scheduling technology, specifically relating to a multi-cluster multi-strategy traffic scheduling system. Background Technology

[0002] System failure refers to an event or state in which a product or part of a product cannot or will not be able to perform its intended function. More than 80% of product failures come from system changes and the iteration of new and old versions of applications. When a failure occurs, it is difficult to quickly restore system services.

[0003] Currently, the difficulties in maintaining existing system faults stem from the following reasons: 1. Overly tight coupling between applications within the system leads to lengthy system rollbacks or application releases, requiring the rollback of multiple applications each time, consuming several hours or even more than ten hours; 2. In special circumstances, there is no environment to verify new releases, making it impossible to meet testing conditions. To address these issues, we have designed a multi-cluster, multi-strategy traffic scheduling system. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the present invention aims to provide a multi-cluster, multi-strategy traffic scheduling system that can solve the problems of long system failure rollback times, lack of environmental verification requirements for new releases, and inability to meet testing conditions. The present invention adopts the following technical solution.

[0005] A multi-cluster, multi-strategy traffic scheduling system, characterized in that it includes a K8S cluster, an A cluster, and a B cluster;

[0006] The K8S cluster includes the traefik command, whose output is connected to the input signals of the Nginx-001 and Nginx-002 commands respectively.

[0007] The K8S cluster is configured with cluster A and cluster B. Cluster A and cluster B each contain one kong command and four pod commands. The output of the kong command is connected to the input of the pod commands.

[0008] The K8S cluster has a middleware module, which contains Nacos, MQ and XXL commands.

[0009] Cluster A and Cluster B can access and store data from the middleware modules within their respective clusters.

[0010] The output of the Nginx-001 command is connected to the input of the kong command in cluster B and cluster A, respectively. The output of the Nginx-002 command is connected to the input of the kong command in cluster B and cluster A, respectively.

[0011] Preferably, a self-developed agent is set up in the K8S cluster. The input end of the self-developed agent is connected to the output end of the Matrix instruction, the output end of the self-developed agent is connected to the input end of the Nacos instruction in the K8S cluster, the output end of the Nacos instruction in the K8S cluster is connected to the input end of the Confd instruction in the K8S cluster, and the output end of the Confd instruction in the K8S cluster is connected to the input end of the Nginx-001 instruction.

[0012] Preferably, the K8S cluster is equipped with a data storage module, which includes MySQL commands, Redis commands, Elasticsearch commands, and Minio commands.

[0013] Cluster A and Cluster B can access the data storage module.

[0014] Preferably, the traffic routing of each module is dynamically configured through nacos+confd+nginx. The output of the user terminal is connected to the input signal of the Nacos command, the output of the Nacos command is connected to the input signal of the Confd command, and the output of the Confd command is connected to the input signal of the Nginx command.

[0015] The specific implementation steps of nacos+confd+nginx are as follows:

[0016] 1. Modify Nacos configuration;

[0017] II. Push Confd configuration;

[0018] III. Push Nginx configuration;

[0019] IV. Update nginx.conf;

[0020] 5. Reload to make the nginx configuration take effect.

[0021] Preferably, the nginx directive stores two configurations, A-upstream and B-upstream, which point to the backend application addresses and ports of the K8S cluster and the A cluster, respectively.

[0022] Preferably, the output terminal on the in-hospital side is connected to the input signal of the traefik command within the K8S cluster.

[0023] Compared with the prior art, the beneficial effects of the present invention are:

[0024] I. This invention's multi-cluster, multi-strategy traffic scheduling system, through the design of a K8S cluster, cluster A, and cluster B, can use nginx commands to switch between clusters A and B. Cluster A is the latest version cluster, while cluster B is a stable version cluster. During normal operation, the version difference between cluster A and cluster B does not exceed one week. If cluster A detects an application failure and identifies it as caused by a release, it will quickly switch all traffic to cluster B for recovery. The technical team can still locate, analyze, and re-release the problem by accessing cluster A, achieving minute-level recovery from the failure. II. This invention's multi-cluster, multi-strategy traffic scheduling system, through the design of a K8S cluster and a self-developed agent, dynamically configures traffic routing for each region using Nacos + confd + nginx. Lua scripts are written to dynamically read the configuration and route traffic to different backend web clusters based on IP ranges, headers, and other dimensions. Runtime rule switching can be achieved within seconds, realizing traffic routing. Attached Figure Description

[0025] Figure 1 This is a system structure block diagram of the present invention;

[0026] Figure 2 This is a structural block diagram of the nacos+confd+nginx part of the present invention;

[0027] Figure 3 This is a flowchart of the nacos+confd+nginx part of the present invention; in the diagram: 1, K8S cluster, 2, A cluster, 3, B cluster, 4, data storage module, 5, internal terminal, 6, self-developed agent, 7, user terminal. Detailed Implementation

[0028] Please see Figure 1-3 The system shown is a multi-cluster, multi-policy traffic scheduling system. It features multi-cluster and traffic control capabilities, as well as regional isolation deployment, batch distribution, and fine-grained traffic management. Specifically, the multi-cluster, multi-policy traffic scheduling system includes K8S cluster 1, cluster A 2, and cluster B 3.

[0029] K8S cluster 1 includes the traefik command. The output of the traefik command is connected to the input signals of the Nginx-001 command and the Nginx-002 command, respectively. K8S cluster 1 contains clusters A2 and B3. Clusters A2 and B3 each contain one kong command and four pod commands. The output of the kong command is connected to the input signal of the pod command. K8S cluster 1 contains a middleware module with Nacos, MQ, and XXL commands. Clusters A2 and B3 can access and store data within their respective middleware modules. The output of the Nginx-001 command is connected to the input signal of the pod command within cluster B3. The input of the `ng` command is connected to the input of the `kong` command within cluster A2. The output of the `Nginx-002` command is connected to the input of the `kong` command within cluster B3 and the input of the `kong` command within cluster A2. Cluster A2 and cluster B3 can be switched using `nginx` commands. Cluster A2 is the latest version cluster, while cluster B3 is a stable version cluster. During normal operation, the version difference between cluster A2 and cluster B3 does not exceed one week. If cluster A2 detects an application failure and identifies it as caused by a release, it will switch all traffic to cluster B3 for rapid recovery. The technical team can still locate, analyze, and repair the problem by accessing cluster A2, and then release and verify the repair, achieving fault recovery within minutes.

[0030] Within the Kubernetes cluster 1, a self-developed agent 6 is configured. The input of agent 6 is connected to the output of the Matrix command, and the output of agent 6 is connected to the input of the Nacos command within the Kubernetes cluster 1. The output of the Nacos command within the Kubernetes cluster 1 is connected to the input of the Confd command within the Kubernetes cluster 1. The output of the Confd command within the Kubernetes cluster 1 is connected to the input of the Nginx-001 command. Traffic routing for each region is dynamically configured through nacos+confd+nginx. Lua scripts are written to dynamically read the configuration and route traffic to different backend web clusters based on IP ranges, headers, and other dimensions. Rule switching can be performed in seconds during runtime to achieve traffic routing.

[0031] K8S cluster 1 has a data storage module 4, which contains MySQL commands, Redis commands, Elasticsearch commands, and Minio commands. Clusters A 2 and B 3 can access data storage module 4.

[0032] Traffic routing for each module is dynamically configured using nacos+confd+nginx. The output of client 7 is connected to the input signal of the Nacos command, the output of the Nacos command is connected to the input signal of the Confd command, and the output of the Confd command is connected to the input signal of the Nginx command. The specific implementation steps of nginx+confd+nacos are as follows: 1. Modify the Nacos configuration; 2. Push the Confd configuration; 3. Push the Nginx configuration; 4. Update nginx.conf; 5. Reload to make the nginx configuration effective.

[0033] The nginx directives contain two configurations, A-upstream and B-upstream, which point to the backend application addresses and ports of K8S cluster 1 and cluster A 2, respectively.

[0034] The output terminal of the 5th side of the hospital is connected to the input signal of the traefik command in the K8S cluster 1.

[0035] When using this system, the self-developed agent 6 uses Futuredog, which is a software that receives control and scheduling to execute specific functions;

[0036] Cluster A2 is the latest version cluster. The latest version will only be released to Cluster A2. Cluster B3 is a stable version cluster. During normal operation, the version difference between Cluster B3 and Cluster A2 will not exceed one week. Application synchronization can only be performed from Cluster A2 to Cluster B3. Batch synchronization and single application synchronization are supported. Any application synchronization to Cluster B3 will first switch all regional traffic to Cluster A2.

[0037] During normal operation, clusters A2 and B3 are synchronized and have the same version. Based on the traffic situation in each region, clusters A2 and B3 each bear a portion of the regional traffic.

[0038] On the application release date, to avoid impacting online services during the release, all regions are switched to Cluster B3 before release. The latest version of the application is released to Cluster A2 environment and released for verification. Regions with sufficient traffic and business complexity are selected and switched to Cluster A2 for online business verification. After sufficient online business verification in a single region, all region traffic is switched to Cluster A2 for verification. If all region verifications are normal, Cluster A2 and Cluster B3 are synchronized, and traffic is switched for load balancing. If the application release date is before a weekend or holiday, the synchronization operation between Cluster A2 and Cluster B3 will be delayed. In this case, Cluster B is used as a disaster recovery backup cluster.

[0039] If cluster A2 detects an application failure and identifies it as being caused by a release, it will switch all traffic to cluster B3 for rapid recovery. The technical team can still locate, analyze, and fix the release verification by accessing cluster A2.

[0040] Some special application scenarios only exist in certain areas or require joint debugging, so after release, this area will be switched back to cluster A2 for joint debugging or verification;

[0041] For a few application modifications, such as database sharding and historical data migration, the cost of adapting the underlying data to clusters A2 and B3 is too high. Based on comprehensive evaluation, if it is only suitable for single-cluster deployment, all traffic must be switched to cluster A2 for online deployment. After verification, clusters A2 and B3 can be synchronized before load balancing can be achieved.

[0042] Operators can use their mobile devices to perform multi-cluster white-screen traffic scheduling based on specified dimensions on the traffic scheduling page, and issue scheduling notifications after the scheduling is completed.

Claims

1. A multi-cluster, multi-strategy traffic scheduling system, characterized in that... :Including K8S cluster (1), A cluster (2) and B cluster (3); The K8S cluster (1) includes the traefik command. The output of the traefik command is connected to the input of the Nginx-001 command and the input of the Nginx-002 command, respectively. The K8S cluster (1) is equipped with cluster A (2) and cluster B (3). Cluster A (2) and cluster B (3) include one kong command and four pod commands. The output of the kong command is connected to the input of the pod command. The K8S cluster (1) has a middleware module, which contains Nacos, MQ and XXL commands; Cluster A (2) and Cluster B (3) can access the middleware modules within their respective clusters for data storage; The output of the Nginx-001 instruction is connected to the input of the kong instruction in cluster B (3) and the input of the kong instruction in cluster A (2), respectively. The output of the Nginx-002 instruction is connected to the input of the kong instruction in cluster B (3) and the input of the kong instruction in cluster A (2), respectively. The K8S cluster (1) is equipped with a self-developed agent (6). The input end of the self-developed agent (6) is connected to the output end of the Matrix instruction. The output end of the self-developed agent (6) is connected to the input end of the Nacos instruction in the K8S cluster (1). The output end of the Nacos instruction in the K8S cluster (1) is connected to the input end of the Confd instruction in the K8S cluster (1). The output end of the Confd instruction in the K8S cluster (1) is connected to the input end of the Nginx-001 instruction. Traffic routing for each module is dynamically configured through nacos+confd+nginx. The output of the user terminal (7) is connected to the input signal of the Nacos command, the output of the Nacos command is connected to the input signal of the Confd command, and the output of the Confd command is connected to the input signal of the Nginx command. The specific implementation steps of nacos+confd+nginx are as follows:

1. Modify Nacos configuration; II. Push Confd configuration; III. Push Nginx configuration; IV. Update nginx.conf; 5. Reload to make the nginx configuration take effect.

2. The multi-cluster multi-strategy traffic scheduling system according to claim 1, characterized in that: The K8S cluster (1) is equipped with a data storage module (4), which contains MySQL commands, Redis commands, ES commands and Minio commands. Cluster A (2) and Cluster B (3) can access the data storage module (4).

3. The multi-cluster multi-strategy traffic scheduling system according to claim 1, characterized in that: The nginx directive contains two configurations, A-upstream and B-upstream, which point to the backend application address and port of the K8S cluster (1) and the A cluster (2), respectively.

4. The multi-cluster multi-strategy traffic scheduling system according to claim 1, characterized in that: The output of the in-hospital terminal (5) is connected to the input signal of the traefik command in the K8S cluster (1).

Images