A multi-cluster cloud native task scheduling method and system based on zero trust

Abstract

The present invention belongs to the field of task scheduling technology, and specifically discloses a multi-cluster cloud native task scheduling method and system based on zero trust, the method comprising: deploying an independent scheduling agent unit and an operation unit in each cluster; when the system starts, the scheduling agent unit carries its own ID to create a Websocket connection with the server through data encryption; the server sends the cloud native task information to the cluster where the scheduling agent unit with the corresponding ID and the connection is located; polling to obtain the cloud native tasks corresponding to each cluster, converting the cloud native tasks into Tekton tasks, deploying and executing them, and monitoring the status changes of Tekton tasks; the system comprises a server, a scheduling agent unit, an operation unit, a message bus, and a container orchestration platform. The present invention can realize efficient cloud native task scheduling in a multi-cluster environment, and improve the security, reliability and scalability of the system.

Description

Technical Field

[0001] The present invention relates to the technical field of task scheduling, and in particular to a multi-cluster cloud native task scheduling method and system based on zero trust. Background Art

[0002] With the rapid development of cloud computing technology, more and more companies are using cloud-native technology to build microservice architectures. In the context of globalization, companies need to deploy and manage tasks in multiple clusters, but these clusters may not be able to communicate directly due to network isolation, which brings challenges to task scheduling.

[0003] Existing task scheduling systems usually rely on centralized schedulers. However, in a multi-cluster environment, this centralized scheduling method is difficult to adapt to the network isolation in a multi-cluster environment, lacks flexibility and scalability, is difficult to meet the needs of global deployment, and has security issues. Data may be hijacked or parsed by a third party during transmission.

[0004] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present invention, and therefore may include information that does not constitute the prior art known to ordinary technicians in the field. Summary of the invention

[0005] The purpose of the present invention is to solve the network isolation problem of cloud native task scheduling in a multi-cluster environment and improve the security and reliability of the system. To this end, a multi-cluster cloud native task scheduling method and system based on zero trust are provided.

[0006] In order to achieve the above object, the technical solution adopted by the present invention is as follows:

[0007] A multi-cluster cloud native task scheduling method based on zero trust includes the following steps:

[0008] Step S1: deploy independent scheduling agent units and operation units in each cluster;

[0009] Step S2: When the system starts, the dispatch agent unit carries its own ID and creates a Websocket connection with the server through data encryption;

[0010] Step S3: According to the received scheduling agent unit ID, the server queries the ID specified in the task table, and sends the cloud native task information to the cluster where the scheduling agent unit with the corresponding ID and the established connection is located for execution;

[0011] Step S4: the operation unit creates a cloud native task according to the cloud native task information, and sends the cloud native task to the container orchestration platform;

[0012] Step S5: Poll to obtain the cloud native tasks corresponding to each cluster, convert the cloud native tasks into Tekton tasks, deploy and execute them, and mark the owner of the Tekton tasks;

[0013] Step S6: monitor the status change of the Tekton task;

[0014] Step S7: When the Tekton task changes, convert the state to a cloud-native task, update the state of the cloud-native task, and repeat step S5;

[0015] When the Tekton task has no changes and ends, a task end domain event is sent to the message bus;

[0016] Step S8: Each cluster monitors the cloud native task completion domain events through the message bus to achieve state synchronization.

[0017] The following is a technical solution further defined in the method of the present invention. In step S2, the data encryption process includes the following steps:

[0018] The HTTP header corresponding to the scheduling agent unit of each cluster carries an x-aa request header, where the x-aa request header is 8 bytes of data, the first 4 bytes are uint32 random number seeds, and the last 4 bytes are the CRC32 code of the ciphertext of the query string after encryption according to the random number;

[0019] When the dispatch agent sends a Websocket connection request to the server, the server parses the query to see if there is an encryption flag.

[0020] If yes, the server parses the x-aa request header, obtains the random number seed, generates a 16-byte random number based on the seed, performs AES encryption based on the random number + query data to obtain the ciphertext, samples the ciphertext CRC32, and obtains the checksum; if no, the server rejects the cluster's connection request;

[0021] Compare the last 4 bytes of the CRC32 code with the checksum calculated by the server;

[0022] If they are the same, the verification passes and a Websocket connection is allowed to be established between the server and the cluster;

[0023] If they are not the same, the verification fails and the server rejects the cluster's connection request.

[0024] The following is a technical solution further defined by the method of the present invention. After a Websocket connection is established between the server and the cluster, data interactions between the server and the cluster are encrypted using a 16-byte random number.

[0025] The following is a technical solution further defined in the method of the present invention. In step S3, according to the received scheduling agent unit ID, the server queries the ID specified in the task table, including the following steps:

[0026] The server queries its own task table to see if there are tasks corresponding to the cluster;

[0027] If the corresponding task does not exist, the corresponding Websocket connection will be rejected;

[0028] If there is a corresponding task, query the task details to see whether the cluster scheduling agent unit ID is included in the corresponding details;

[0029] If the cluster's scheduling agent unit ID is not included, the corresponding Websocket connection is rejected;

[0030] If the scheduling agent unit ID of the cluster is included, a corresponding Websocket connection is established, and the cloud native task information is sent to the cluster where the scheduling agent unit with the corresponding ID and the established connection is located for execution.

[0031] The following is a technical solution further defined by the method in the present invention. In step S5, when the Tekton task is deployed and executed, a log resource is created, the cloud native task and its Tekton task continuously write data to the log resource, the cluster's operation unit continuously reads the log resource, and reports to the server through the scheduling agent unit. During the reporting process, at the moment when any disconnection occurs between the cluster and the server, the log's OFFSET mark is performed. When reconnected, reporting continues from the log's OFFSET mark position.

[0032] A multi-cluster cloud native task scheduling system based on zero trust, used to implement the above-mentioned multi-cluster cloud native task scheduling method based on zero trust, including a server, a scheduling agent unit, an operation unit and a message bus;

[0033] The server, as the core of the entire system, is responsible for coordinating communications between clusters, managing security policies, and scheduling cloud native tasks;

[0034] The scheduling agent unit is deployed in each cluster to establish secure communication with the server and continuously report heartbeats;

[0035] The operation unit is deployed in each cluster to interact with the container orchestration platform and listen to resource events;

[0036] The message bus is used to synchronize the task completion status between each cluster.

[0037] The following is a technical solution further defined by the system in the present invention, wherein the server includes a data parsing component, a data encryption component, a checksum calculation and comparison component, a task judgment component, an ID judgment component and a task information delivery component;

[0038] A data parsing component, used to parse the encrypted identifier used in the query string and parse the x-aa request header carried in the HTTP header corresponding to the scheduling agent unit;

[0039] Data encryption component, used to encrypt random number + query data with AES;

[0040] The checksum calculation and comparison component is used to obtain the crc32 code of the encrypted ciphertext and compare it with the crc32 code of the 4 bytes after the x-aa request header carried in the HTTP header corresponding to the scheduling agent unit;

[0041] The task judgment component determines whether there is a task corresponding to the cluster in the task table based on its own task table;

[0042] ID judgment component, used to determine whether the task details contain the cluster's scheduling agent unit ID;

[0043] The task information delivery component delivers the cloud native task information to the cluster where the connected scheduling agent unit is located based on successful data analysis and verification, successful task judgment, and successful ID judgment.

[0044] The following is a technical solution further defined by the system in the present invention, wherein the scheduling agent unit includes a connection request component, a task sending and receiving component, a log reporting component and a log reconnection component;

[0045] The connection request component is used to initiate a Websocket connection request to the server with its own ID;

[0046] The task sending and receiving component is used to receive the cloud native task information sent by the server and forward the cloud native task information to the operation unit;

[0047] Log reporting component, used to report log resources to the server;

[0048] The log marking component is used to mark the log with OFFSET at the breakpoint, so as to facilitate the continuation of reporting from the OFFSET mark position of the log.

[0049] The following is a technical solution further defined by the system in the present invention, wherein the operation unit includes a cloud native task creation component, a cloud native task sending component, a task monitoring component, a cloud native task status update component, and a message bus monitoring component;

[0050] The cloud native task creation component is used to create cloud native tasks based on cloud native task information;

[0051] Cloud native task sending component, used to send cloud native tasks to the container orchestration platform;

[0052] Task monitoring component, used to monitor the status changes of Tekton tasks;

[0053] The cloud-native task status update component updates the cloud-native task status based on the status change of the Tekton task;

[0054] The message bus listening component is used to listen to the cloud native task completion domain events of the message bus.

[0055] The following is a technical solution further defined by the system in the present invention, wherein the container orchestration platform includes a task polling component, a task conversion component, a task deployment execution component, a task marking component and a log generation component;

[0056] The task polling component is used to poll cloud native tasks to obtain the cloud native tasks corresponding to each cluster;

[0057] Task conversion component, used to convert cloud-native tasks to Tekton tasks, or vice versa;

[0058] Task deployment and execution component, used to deploy and execute Tekton tasks;

[0059] A task tagging component, which is used to tag the owner of a Tekton task, thus allowing cascading deletion of Tekton tasks when the owner is deleted;

[0060] The log generation component is used to create pod logs and write them to log storage.

[0061] Compared with the prior art, the present invention has the following technical effects:

[0062] 1. The present invention deploys independent scheduling agent units and operation units in each cluster and establishes a Websocket connection with the server. The server is responsible for coordinating communications between clusters, managing security policies, and scheduling cloud native tasks, thereby realizing cross-cluster task scheduling and then realizing state synchronization between clusters through the message bus.

[0063] 2. Perform encryption processing at the data level, including encryption and verification when creating a Websocket connection, to prevent traffic from being hijacked and parsed by a third party.

[0064] In summary, the present invention can realize efficient cloud-native task scheduling in a multi-cluster environment, improving the security, reliability and scalability of the system.

[0065] The present invention is further described below in conjunction with the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0067] Figure 1 It is a schematic flow chart of the method of the present invention;

[0068] Figure 2 It is a schematic diagram of the process of data encryption in the present invention;

[0069] Figure 3 It is a schematic diagram of the system connection relationship of the present invention. DETAILED DESCRIPTION

[0070] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the specific embodiments of the present invention are described in detail below in conjunction with the accompanying drawings. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention, so the present invention is not limited by the specific embodiments disclosed below.

[0071] like Figure 1 As shown, this embodiment provides a multi-cluster cloud native task scheduling method based on zero trust, including the following steps:

[0072] Step S1: deploy independent scheduling agent units and operation units in each cluster.

[0073] Step S2: When the system starts, the scheduling agent unit carries its own ID and creates a Websocket connection (Websocket connection is referred to as WS connection) with the server through data encryption.

[0074] like Figure 2 As shown, the data encryption process includes the following steps:

[0075] The HTTP header corresponding to the scheduling agent unit of each cluster carries an x-aa request header, where the x-aa request header is 8 bytes of data, the first 4 bytes are uint32 random number seeds, and the last 4 bytes are the CRC32 code of the ciphertext of the query string after encryption according to the random number;

[0076] When the dispatch agent sends a Websocket connection request to the server, the server parses the query to see if there is an encryption flag.

[0077] If yes, the server parses the x-aa request header, obtains the random number seed, generates a 16-byte random number based on the seed, performs AES encryption based on the random number + query data to obtain the ciphertext, samples the ciphertext CRC32, and obtains the checksum; if no, the server rejects the cluster's connection request;

[0078] Compare the last 4 bytes of the CRC32 code with the checksum calculated by the server;

[0079] If they are the same, the verification passes and a Websocket connection is allowed to be established between the server and the cluster;

[0080] If they are not the same, the verification fails and the server rejects the cluster's connection request.

[0081] After the Websocket connection is established between the server and the cluster, the data interaction between the server and the cluster is encrypted using a 16-byte random number.

[0082] Step S3: According to the received scheduling agent unit ID, the server queries the ID specified in the task table, and sends the cloud native task information to the cluster where the scheduling agent unit with the corresponding ID and the established connection is located for execution.

[0083] According to the received scheduling agent unit ID, the server queries the ID specified in the task table, including the following steps:

[0084] The server queries its own task table to see if there are tasks corresponding to the cluster;

[0085] If the corresponding task does not exist, the corresponding Websocket connection will be rejected;

[0086] If there is a corresponding task, query the task details to see whether the cluster scheduling agent unit ID is included in the corresponding details;

[0087] If the cluster's scheduling agent unit ID is not included, the corresponding Websocket connection is rejected;

[0088] If the scheduling agent unit ID of the cluster is included, a corresponding Websocket connection is established, and the cloud native task information is sent to the cluster where the scheduling agent unit with the corresponding ID and the established connection is located for execution.

[0089] Step S4: The operation unit creates a cloud native task according to the cloud native task information, and sends the cloud native task to the container orchestration platform.

[0090] Step S5: Poll to obtain the cloud native tasks corresponding to each cluster, convert the cloud native tasks into Tekton tasks, deploy and execute them, and mark the owner of the Tekton tasks.

[0091] When the Tekton task is deployed and executed, log resources are created. The cloud native task and its Tekton task continuously write data to the log resources. The cluster's operation unit continuously reads the log resources and reports them to the server through the scheduling agent unit. During the reporting process, if the cluster and the server are disconnected at any time, the log's OFFSET mark is performed. When reconnected, reporting continues from the log's OFFSET mark position.

[0092] Step S6: Monitor the status changes of the Tekton task.

[0093] Step S7: When the Tekton task changes, convert the state to a cloud-native task, update the state of the cloud-native task, and repeat step S5;

[0094] When a Tekton task has no changes and ends, a task end domain event is sent to the message bus.

[0095] Step S8: Each cluster monitors the cloud-native task completion domain events through the message bus to achieve state synchronization.

[0096] A multi-cluster cloud-native task scheduling system based on zero trust, mainly composed of a server, a scheduling agent unit, an operation unit and a message bus.

[0097] The server, as the core of the entire system, is responsible for coordinating communications between clusters, managing security policies, and scheduling cloud native tasks.

[0098] Specifically, the server includes a data parsing component, a data encryption component, a checksum calculation and comparison component, a task judgment component, an ID judgment component, and a task information delivery component. The data parsing component is used to parse the encrypted identifier used in the query string and the x-aa request header carried by the HTTP header corresponding to the scheduling agent unit. The data encryption component is used to encrypt the random number + query data with AES. The checksum calculation and comparison component is used to obtain the CRC32 code of the encrypted ciphertext and compare it with the CRC32 code of the 4 bytes after the x-aa request header carried by the HTTP header corresponding to the scheduling agent unit. The task judgment component, based on its own task table, determines whether there is a task corresponding to the cluster in the task table. The ID judgment component is used to determine whether the task details contain the scheduling agent unit ID of the cluster. The task information delivery component, based on the successful data parsing verification, successful task judgment, and successful ID judgment, sends the cloud native task information to the cluster where the scheduling agent unit that has established the connection is located for execution.

[0099] The scheduling agent unit is deployed in each cluster to establish secure communication with the server and continuously report heartbeats.

[0100] Specifically, the scheduling agent unit includes a connection request component, a task sending and receiving component, a log reporting component, and a log reconnection component. The connection request component is used to initiate a Websocket connection request to the server with its own ID. The task sending and receiving component is used to receive the cloud native task information sent by the server and forward the cloud native task information to the operation unit. The log reporting component is used to report log resources to the server. The log marking component is used to mark the log with OFFSET at the breakpoint to facilitate continued reporting from the OFFSET mark position of the log.

[0101] The operation unit is deployed in each cluster to interact with the container orchestration platform and listen to resource events.

[0102] Specifically, the operation unit includes a cloud native task creation component, a cloud native task sending component, a task monitoring component, a cloud native task status update component, and a message bus monitoring component. The cloud native task creation component is used to create a cloud native task according to the cloud native task information. The cloud native task sending component is used to send the cloud native task to the container orchestration platform. The task monitoring component is used to monitor the status changes of the Tekton task. The cloud native task status update component updates the cloud native task status based on the status changes of the Tekton task. The message bus monitoring component is used to monitor the cloud native task end domain events of the message bus.

[0103] Specifically, the container orchestration platform includes a task polling component, a task conversion component, a task deployment execution component, a task marking component, and a log generation component. The task polling component is used to poll cloud native tasks to obtain cloud native tasks corresponding to each cluster. The task conversion component is used to convert cloud native tasks into Tekton tasks, or convert Tekton tasks into cloud native tasks. The task deployment execution component is used to deploy and execute Tekton tasks. The task marking component is used to mark the owner of the Tekton task, so that when the owner is deleted, cascade deletion of the Tekton task is allowed. The log generation component is used to create pod logs and write them to log storage.

[0104] The message bus is used to synchronize the task completion status between each cluster.

[0105] The working process of this embodiment will be further described below:

[0106] like Figure 3As shown, scheduling agent unit A and operation unit A are deployed in cluster A, scheduling agent unit B and operation unit B are deployed in cluster B, and scheduling agent unit C and operation unit C are deployed in cluster C.

[0107] The scheduling agent unit A in cluster A carries its own ID and x-aa request header to send a Websocket connection request to initially establish a Websocket connection (WS connection for short) with the server. The server finds that the ID specified in the task table contains the ID of the scheduling agent unit A, and formally establishes a WS connection. The server sends the cloud native task information to cluster A for execution. The operation unit A creates a cloud native task based on the cloud native task information of the server and sends the cloud native task to the container orchestration platform. The container orchestration platform polls to obtain the cloud native tasks of cluster A, converts the cloud native tasks into Tekton tasks, deploys and executes them, and marks the owner of the Tekton task (cluster A) (if cluster A is deleted later, the Tekton tasks of cluster A can be cascaded and deleted). In the above process, the status changes of the Tekton tasks are monitored. When the Tekton tasks change, the operation unit A converts the status into the cloud native tasks, updates the status of the cloud native tasks, and sends the cloud native tasks to the container orchestration platform. The container orchestration platform polls to obtain the cloud native tasks of cluster A, and repeats this cycle until the Tekton tasks are unchanged and end. Finally, the task end domain event of cluster A is sent to the message bus.

[0108] And so on:

[0109] The scheduling agent unit B in cluster B carries its own ID and x-aa request header to send a Websocket connection request to initially establish a Websocket connection (WS connection for short) with the server. The server finds that the ID specified in the task table contains the ID of the scheduling agent unit B, and formally establishes a WS connection. The server sends the cloud native task information to cluster B for execution. Operation unit B creates a cloud native task based on the cloud native task information of the server and sends the cloud native task to the container orchestration platform. The container orchestration platform polls to obtain the cloud native tasks of cluster B, converts the cloud native tasks into Tekton tasks, deploys and executes them, and marks the owner of the Tekton task (cluster B) (if cluster B is deleted later, the Tekton tasks of cluster B can be cascaded and deleted). In the above process, the status changes of the Tekton tasks are monitored. When the Tekton tasks change, the operation unit B converts the status into the cloud native tasks, updates the status of the cloud native tasks, and sends the cloud native tasks to the container orchestration platform. The container orchestration platform polls to obtain the cloud native tasks of cluster B, and repeats this cycle until the Tekton tasks are unchanged and end. Finally, the task end domain event of cluster B is sent to the message bus.

[0110] The scheduling agent unit C in cluster C carries its own ID and x-aa request header to send a Websocket connection request to initially establish a Websocket connection (WS connection for short) with the server. The server finds that the ID specified in the task table contains the ID of the scheduling agent unit C, and formally establishes a WS connection. The server sends the cloud native task information to cluster C for execution. The operation unit C creates a cloud native task based on the cloud native task information of the server and sends the cloud native task to the container orchestration platform. The container orchestration platform polls to obtain the cloud native tasks of cluster C, converts the cloud native tasks into Tekton tasks, deploys and executes them, and marks the owner of the Tekton task (cluster C) (if cluster C is deleted later, the Tekton tasks of cluster C can be cascaded and deleted). In the above process, the status changes of the Tekton tasks are monitored. When the Tekton tasks change, the operation unit C converts the status into the cloud native tasks, updates the status of the cloud native tasks, and sends the cloud native tasks to the container orchestration platform. The container orchestration platform polls to obtain the cloud native tasks of cluster C, and repeats this cycle until the Tekton tasks are unchanged and end. Finally, the task end domain event of cluster C is sent to the message bus.

[0111] Thus, cluster A can obtain the task completion domain events of cluster B and cluster C through the message bus. Cluster B can obtain the task completion domain events of cluster A and cluster C through the message bus. Cluster C can obtain the task completion domain events of cluster A and cluster B through the message bus. Thus, state synchronization is achieved.

[0112] The above is only a preferred embodiment of the present invention, and does not limit the present invention in any form. Any technician familiar with the art can make many possible changes and modifications to the technical solution of the present invention by using the above disclosed methods and technical contents without departing from the scope of the technical solution of the present invention, or modify it into an equivalent embodiment of equivalent changes. Therefore, all equivalent changes made according to the shape, structure and principle of the present invention without departing from the content of the technical solution of the present invention should be included in the protection scope of the present invention.

Claims

1. A multi-cluster cloud native task scheduling method based on zero trust, characterized in that: The following steps are involved: Step S1: deploy independent scheduling agent units and operation units in each cluster; Step S2: When the system starts, the dispatch agent unit carries its own ID and creates a Websocket connection with the server through data encryption; Step S3: According to the received scheduling agent unit ID, the server queries the ID specified in the task table, and sends the cloud native task information to the cluster where the scheduling agent unit with the corresponding ID and the established connection is located for execution; Step S4: the operation unit creates a cloud native task according to the cloud native task information, and sends the cloud native task to the container orchestration platform; Step S5: Poll to obtain the cloud native tasks corresponding to each cluster, convert the cloud native tasks into Tekton tasks, deploy and execute them, and mark the owner of the Tekton tasks; Step S6: monitor the status change of the Tekton task; Step S7: When the Tekton task changes, convert the state to a cloud-native task, update the state of the cloud-native task, and repeat step S5; When the Tekton task has no changes and ends, a task end domain event is sent to the message bus; Step S8: Each cluster monitors the cloud native task completion domain events through the message bus to achieve state synchronization.

2. A multi-cluster cloud native task scheduling method based on zero trust as claimed in claim 1, characterized in that: In step S2, the data encryption process includes the following steps: The HTTP header corresponding to the scheduling agent unit of each cluster carries an x-aa request header, where the x-aa request header is 8 bytes of data, the first 4 bytes are uint32 random number seeds, and the last 4 bytes are the CRC32 code of the ciphertext of the query string after encryption according to the random number; When the dispatch agent sends a Websocket connection request to the server, the server parses the query to see if there is an encryption flag. If yes, the server parses the x-aa request header, obtains the random number seed, generates a 16-byte random number based on the seed, performs AES encryption based on the random number + query data to obtain the ciphertext, samples the ciphertext CRC32, and obtains the checksum; if no, the server rejects the cluster's connection request; Compare the last 4 bytes of the CRC32 code with the checksum calculated by the server; If they are the same, the verification passes and a Websocket connection is allowed to be established between the server and the cluster; If they are not the same, the verification fails and the server rejects the cluster's connection request.

3. A multi-cluster cloud native task scheduling method based on zero trust as described in claim 2, characterized in that: After the Websocket connection is established between the server and the cluster, the data interaction between the server and the cluster is encrypted using a 16-byte random number.

4. A multi-cluster cloud native task scheduling method based on zero trust as described in claim 2, characterized in that: In step S3, according to the received scheduling agent unit ID, the server queries the ID specified in the task table, including the following steps: The server queries its own task table to see if there are tasks corresponding to the cluster; If the corresponding task does not exist, the corresponding Websocket connection will be rejected; If there is a corresponding task, query the task details to see whether the cluster scheduling agent unit ID is included in the corresponding details; If the cluster's scheduling agent unit ID is not included, the corresponding Websocket connection is rejected; If the scheduling agent unit ID of the cluster is included, a corresponding Websocket connection is established, and the cloud native task information is sent to the cluster where the scheduling agent unit with the corresponding ID and the established connection is located for execution.

5. A multi-cluster cloud native task scheduling method based on zero trust as claimed in claim 1, characterized in that: In step S5, when the Tekton task is deployed and executed, log resources are created. The cloud native task and its Tekton task continuously write data to the log resources. The cluster's operation unit continuously reads the log resources and reports to the server through the scheduling agent unit. During the reporting process, if there is any disconnection between the cluster and the server, the log's OFFSET mark is performed. When reconnected, reporting continues from the log's OFFSET mark position.

6. A multi-cluster cloud native task scheduling system based on zero trust, used to implement a multi-cluster cloud native task scheduling method based on zero trust as described in any one of claims 1-5, characterized in that: It includes a server, a scheduling agent unit, an operation unit and a message bus; The server, as the core of the entire system, is responsible for coordinating communications between clusters, managing security policies, and scheduling cloud native tasks; The scheduling agent unit is deployed in each cluster to establish secure communication with the server and continuously report heartbeats; The operation unit is deployed in each cluster to interact with the container orchestration platform and listen to resource events; The message bus is used to synchronize the task completion status between each cluster.

7. A zero-trust based multi-cluster cloud native task scheduling system as claimed in claim 6, characterized in that: The server includes a data parsing component, a data encryption component, a checksum calculation and comparison component, a task judgment component, an ID judgment component and a task information delivery component; A data parsing component, used to parse the encrypted identifier used in the query string and parse the x-aa request header carried in the HTTP header corresponding to the scheduling agent unit; Data encryption component, used to encrypt random number + query data with AES; The checksum calculation and comparison component is used to obtain the crc32 code of the encrypted ciphertext and compare it with the crc32 code of the 4 bytes after the x-aa request header carried in the HTTP header corresponding to the scheduling agent unit; The task judgment component determines whether there is a task corresponding to the cluster in the task table based on its own task table; ID judgment component, used to determine whether the task details contain the cluster's scheduling agent unit ID; The task information delivery component delivers the cloud native task information to the cluster where the connected scheduling agent unit is located based on successful data analysis and verification, successful task judgment, and successful ID judgment.

8. A multi-cluster cloud native task scheduling system based on zero trust as claimed in claim 6, characterized in that: The scheduling agent unit includes a connection request component, a task sending and receiving component, a log reporting component and a log reconnection component; The connection request component is used to initiate a Websocket connection request to the server with its own ID; The task sending and receiving component is used to receive the cloud native task information sent by the server and forward the cloud native task information to the operation unit; Log reporting component, used to report log resources to the server; The log marking component is used to mark the log with OFFSET at the breakpoint, so as to facilitate the continuation of reporting from the OFFSET mark position of the log.

9. A multi-cluster cloud native task scheduling system based on zero trust as claimed in claim 6, characterized in that: The operation unit includes a cloud native task creation component, a cloud native task sending component, a task monitoring component, a cloud native task status update component and a message bus monitoring component; The cloud native task creation component is used to create cloud native tasks based on cloud native task information; Cloud native task sending component, used to send cloud native tasks to the container orchestration platform; Task monitoring component, used to monitor the status changes of Tekton tasks; The cloud-native task status update component updates the cloud-native task status based on the status change of the Tekton task; The message bus listening component is used to listen to the cloud native task completion domain events of the message bus.

10. A zero-trust based multi-cluster cloud native task scheduling system as claimed in claim 6, characterized in that: The container orchestration platform includes a task polling component, a task conversion component, a task deployment execution component, a task marking component and a log generation component; The task polling component is used to poll cloud native tasks to obtain the cloud native tasks corresponding to each cluster; Task conversion component, used to convert cloud-native tasks to Tekton tasks, or vice versa; Task deployment and execution component, used to deploy and execute Tekton tasks; A task tagging component, which is used to tag the owner of a Tekton task, thus allowing cascading deletion of Tekton tasks when the owner is deleted; The log generation component is used to create pod logs and write them to log storage.

Images