A task authentication and scheduling method, a task scheduler and a storage medium

Abstract

The application discloses a task authentication and scheduling method, a task scheduler and a storage medium, relates to the technical field of distributed systems, and realizes identity authentication on an authentication request through container group configuration in the task scheduler. Each container group can flexibly configure resource quotas according to actual needs, maximally avoids unreasonable resource allocation, and has strong expansion capability. Each container group is independent of each other and redundant to each other, avoids single-point dependence of authentication services, improves the reliability of the whole authentication and task scheduling process, guarantees the fault tolerance of the task scheduler, and meanwhile, each container group can adopt different authentication strategies for identity authentication, so that the scheduler can effectively adapt to various types of authentication requests existing in a multi-data center scenario, realizes unified identity management and cross-cluster resource collaborative scheduling, improves authentication efficiency, and realizes more fine-granularity authorization based on request attributes during task scheduling execution, and further improves the security of the authentication and scheduling process.

Description

Technical Field

[0001] This invention relates to the field of distributed systems technology, and in particular to a task authentication and scheduling method, a task scheduler, and a storage medium. Background Technology

[0002] In high-performance computing and distributed task cluster environments, the cluster task management scheduler is a key tool for simplifying distributed resource management and job scheduling. It provides core functions such as task submission, priority scheduling, resource allocation, user access control, and workflow management, playing a crucial role in improving computing resource utilization and avoiding resource conflicts. To prevent resource abuse and ensure data security, the cluster task management scheduler needs to authenticate the user submitting the task before performing corresponding resource scheduling based on the authentication result.

[0003] It is evident that how to authenticate the identity of users submitting tasks and schedule tasks is a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0004] The purpose of this invention is to provide a task authentication and scheduling method, a task scheduler, and a storage medium, which can solve the problem of how the task scheduler can efficiently complete the authentication of user-submitted tasks and task scheduling in a distributed task cluster environment.

[0005] To address the aforementioned technical problems, embodiments of the present invention provide a task authentication and scheduling method, applied to a task scheduler, wherein several container groups are pre-integrated in the task scheduler; the task authentication and scheduling method includes: If an authentication request is received, it is assigned to the corresponding container group based on the authentication characteristics of the request; the container group is configured to perform identity authentication on the received authentication request using a preset authentication strategy; Add the task request associated with the authenticated request to the scheduling queue; Determine whether the operation of each task request is within the scope of permissions based on the request attributes of the task request; If the requested operation is within the authorized scope, the task request will be executed according to the scheduling policy of the scheduling queue.

[0006] In some embodiments, before assigning an authentication request to a corresponding container group based on the authentication characteristics of the authentication request, the method further includes: Check if the task scheduler's authentication resource pool is in normal working order; If the authentication resource pool is in normal working order, the authentication request will be verified. If the authentication request passes the verification, proceed to the step of assigning the authentication request to the corresponding container group based on the authentication characteristics of the authentication request.

[0007] In some embodiments, each container group is bound to a unique corresponding tag; the authentication request is assigned to the corresponding container group based on the authentication characteristics of the authentication request, including: Determine the authentication characteristics of the authentication request; the authentication characteristics include one or more combinations of the authentication method type, security level, and expected processing time of the authentication request. Based on the authentication features of the authentication request, the target tag that matches the authentication request is determined from several tags, and the authentication request is labeled with the target tag. Based on the binding relationship between container groups and tags, authentication requests are assigned to the container group corresponding to the target tag.

[0008] In some embodiments, the container group generates authentication information corresponding to the authentication request when the authentication request passes authentication; the task authentication and scheduling method further includes: Identity authentication information is encapsulated and stored using blockchain.

[0009] In some embodiments, the task authentication and scheduling method further includes: Parse the authentication request to obtain the authentication information from it; The authentication information is decrypted so that the container group can use the decrypted authentication information to authenticate the received authentication request.

[0010] In some embodiments, the scheduling queue includes several sub-queues with different priorities; adding the task request associated with the authentication request that has passed authentication to the scheduling queue includes: The task requests associated with the authentication request are added to the corresponding sub-queue based on the authentication method type and / or the priority of the authentication request.

[0011] In some embodiments, the task authentication and scheduling method further includes: For any container group, determine the performance metrics for that container group; the performance metrics include one or more combinations of resource utilization, request load, queue length, and response latency. Adjust the number of container instances created in any container group based on the performance metrics of that container group.

[0012] In some embodiments, the task authentication and scheduling method further includes: Determine the real-time available resources in the authentication resource pool of the task scheduler; For any container instance in any container group, determine the real-time load of that container instance; Determine the priority coefficient corresponding to the priority of the authentication request currently being processed by any container instance; The first weight is configured based on real-time load; the first weight is positively correlated with the real-time load. The second weight is allocated based on real-time available resources; the second weight is positively correlated with real-time available resources. The third weight is configured based on the priority coefficient; the third weight is positively correlated with the priority coefficient. The sum of the first product, the second product, and the third product is determined as the resource quota allocated to any container instance; wherein, the first product is the product between real-time load and the first weight; the second product is the product between real-time available resources and the second weight; and the third product is the product between the priority coefficient and the third weight.

[0013] To address the aforementioned technical problems, embodiments of the present invention also provide a task scheduler, comprising: Memory, used to store computer programs; A processor is used to execute computer programs to implement the steps of the aforementioned task authentication and scheduling method.

[0014] To address the aforementioned technical problems, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the aforementioned task authentication and scheduling method.

[0015] As can be seen from the above technical solution, identity authentication for authentication requests is achieved through container group configuration in the task scheduler. Each container group is independent and redundant, and each container group can use different authentication strategies for identity authentication. The beneficial effects of this invention are that each container group can flexibly configure resource quotas according to actual needs, minimizing unreasonable resource allocation and providing strong scalability; it avoids single-point dependency of authentication services, improves the reliability of the entire authentication and task scheduling process, and ensures the fault tolerance of the task scheduler; it enables unified identity management and cross-cluster resource collaborative scheduling, improving authentication efficiency; and it achieves more granular authorization based on request attributes during task scheduling execution, further enhancing the security of the authentication and scheduling process. Attached Figure Description

[0016] To more clearly illustrate the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a task authentication and scheduling method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of a task authentication and scheduling implementation process provided by an embodiment of the present invention; Figure 3 This is a schematic diagram of a task scheduler provided in an embodiment of the present invention. Detailed Implementation

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

[0019] The terms "comprising" and "having," and any variations thereof, in the specification and accompanying drawings of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may include steps or units not listed.

[0020] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] Next, we will describe in detail a task authentication and scheduling method provided by an embodiment of the present invention, which is applied to a task scheduler, wherein several container groups are pre-integrated in the task scheduler; see [link to previous document]. Figure 1 As shown, Figure 1 This is a flowchart illustrating a task authentication and scheduling method provided in an embodiment of the present invention. The task authentication and scheduling method includes: S11: If an authentication request is received, the authentication request is assigned to the corresponding container group based on the authentication characteristics of the authentication request; the container group is configured to perform identity authentication on the received authentication request using a preset authentication strategy; It's easy to understand that, to avoid strong coupling between authentication logic and cluster management (especially task scheduling), this invention pre-integrates several container groups into the task scheduler. Each container group can independently authenticate received authentication requests. Therefore, upon receiving an authentication request, it can be forwarded to a specific container group. The allocation relationship between different authentication requests and corresponding container groups can be implemented based on the authentication characteristics of the request. The authentication request is forwarded to the corresponding container group, establishes a connection, and the container instance node in the container group initiates the authentication process corresponding to the request, responding to the authentication request according to a specific preset authentication strategy. This achieves authentication of the request and its corresponding user, enabling subsequent task management (especially task scheduling management) based on the authentication results. Each container group works independently, effectively avoiding single-point performance bottlenecks in the authentication process. If one container group fails, other container groups can effectively take over the relevant authentication process, ensuring a certain degree of fault tolerance. A multimodal authentication module is implemented through the design of several container groups.

[0022] It should be noted that this application does not impose specific limitations on the specific types and implementation methods of each container group in the scheduler. Typically, each container group employs different preset authentication strategies for identity authentication, enabling the scheduler to effectively handle different authentication requests and support different authentication methods. This is particularly beneficial in cross-environment collaborative application scenarios, adapting to multi-datacenter scenarios, achieving unified identity management and cross-cluster resource collaborative scheduling, and improving authentication efficiency. Furthermore, the number of container groups configured in the scheduler and the corresponding preset authentication strategies for each container group can be flexibly set and adjusted according to actual application needs. This application does not impose specific limitations here. When a new authentication strategy or method is required for identity authentication, the new authentication technology can be extended and integrated directly by creating new container groups programmatically. This allows for hot-swappable adjustment of authentication methods without downtime or code / configuration modifications. Only registering a new container instance and updating the load balancing rules are required; adding a new authentication method can be achieved without downtime or modification of the core code configuration, simplifying maintenance. The entire authentication process has strong scalability, supporting different authentication methods, and can be extended to include new authentication strategies by adjusting the number of container groups. This application does not specify the authentication strategy adopted by each container group or the specific authentication method within that strategy. Authentication methods may include username and password authentication, token authentication, zero-knowledge proof, etc. This application also does not specify how the container group implements the identity authentication process. After the authentication request is successfully authenticated, the container group will generate corresponding identity authentication information and return it to the user corresponding to the authentication request. This allows the user to prove the legitimacy of their identity when submitting task requests by including this identity authentication information.

[0023] It is understandable that a container group (Pod) is a logical scheduling unit in distributed cluster management. Specifically, it can be the most basic and smallest deployment and scheduling unit in a container orchestration system (such as Kubernetes or Azure Container Instances). Essentially, a container group is a software-defined logical aggregation unit, implemented through operating system-level virtualization technologies. The authentication request is submitted by the user to the task scheduler. It can be an authentication request sent by the user before submitting a task request. In this case, after successful authentication, the user sends the task request based on the received authentication information, which carries the authentication information. Alternatively, the authentication request and the task request can be implemented together in a single request. That is, the user sends a request to the scheduler, which serves as both an authentication request and a task request. In this case, after successful authentication, the request can be added to the scheduling queue as a task request for processing. This application does not specifically limit the authentication characteristics of the authentication request; it can be the authentication method corresponding to the authentication request. In practical applications, other criteria can also be used to allocate authentication requests to different container groups, and this application does not impose any special limitations on these criteria.

[0024] Furthermore, to further decouple the authentication process, a dedicated intelligent load balancer can be added to the task scheduler to handle the allocation of authentication requests. User-submitted authentication requests are directly sent to the intelligent load balancer, which then forwards the requests to the correct container group based on different authentication characteristics (e.g., different authentication methods corresponding to the authentication request). This application does not impose specific limitations on the specific type and implementation method of the intelligent load balancer; it can be implemented by adding a separate hardware device to the scheduler or by integrating it directly into the scheduler as a software module.

[0025] S12: Add the task request associated with the authenticated request to the scheduling queue; It is understandable that after an authentication request passes authentication, the task request associated with that authentication request is added to the scheduling queue, where it awaits scheduling and execution. This application does not specifically limit the specific type or implementation of the scheduling queue. The scheduling queue is a global queue within the scheduler; all task requests associated with authentication requests from any container group after authentication are added to this queue. The scheduler manages and schedules the waiting task requests in the queue according to a preset scheduling strategy. The task request associated with the authentication request refers to the task request carrying the authentication information corresponding to the authentication request, and is generally a request sent by the same user.

[0026] S13: Determine whether the operation of each task request is within the permission scope based on the request attributes of the task request; It's easy to understand that, to ensure security, after a user's request passes authentication, permission matching is required to determine if a specific task request falls within the corresponding permission scope. To improve the granularity of permission control, this application uses the request attributes of the task request for permission matching, specifically employing the ABAC engine (Attribute-Based Access Control). This engine performs permission matching based on attribute-based access control, not relying on predefined roles or permissions. Instead, it calculates access permissions in real-time based on request attributes such as user, resource, and environment, and can dynamically adjust permissions based on different attributes. This application does not specifically limit the specific types and implementation methods of request attributes. Specifically, the ABAC engine can check the user attributes of the task request, such as department, role, and permission tags, and their match with the corresponding task operations. The permission scope corresponding to a task request refers to the range of operations and / or resources that the user corresponding to that task request is allowed to perform. If the user attributes of the task request match the task operation corresponding to the task request, that is, if the user attributes indicate that the permission scope of the user corresponding to the task request matches the permission scope of the task operation corresponding to the task request, then the task request is allowed to be executed; otherwise, the task request is rejected and the reason for the failure of the task request is recorded as insufficient permissions.

[0027] It should be noted that the task operations corresponding to the task request can all be obtained directly from the task request itself, and are generally included in the task request when the user terminal initiates the task request. User attributes of the task request can also be obtained directly from the task request, for example, from the user's authentication information returned by the scheduler after successful authentication. This application does not impose any special restrictions on the methods for obtaining user attributes and corresponding task operations of task requests. Implementing access control through the ABAC engine allows for more granular authorization based on user attributes such as department and role. Even with log separation, errors and anomalies can be effectively detected, facilitating more comprehensive and accurate task management and maintenance.

[0028] S14: If the operation requested by the task is within the scope of the permissions, the task request will be executed according to the scheduling policy of the scheduling queue.

[0029] It is understandable that if a task request passes authentication and matches the corresponding permission scope, it can wait in the scheduling queue for the scheduler to schedule and execute it. In other words, a task request must simultaneously meet both the conditions of authentication validity and permission matching to be scheduled for execution. The scheduler will respond to each task request in the scheduling queue according to a specific scheduling strategy, initiating the execution of the task operation corresponding to that request. This also marks the end of the authentication and scheduling of that task request. This application does not impose specific limitations on the specific scheduling strategy; the scheduler can be set and adjusted according to actual application needs.

[0030] See Figure 2 As shown, Figure 2 This is a schematic diagram illustrating a task authentication and scheduling implementation process provided by an embodiment of the present invention. As a specific embodiment, the task authentication and scheduling method provided by the present invention covers the entire process from user authentication request submission to authentication request processing, and then to role and permission allocation. Figure 2 Each module shown is a functional module integrated into the scheduler. Authentication requests and / or task requests submitted by the user terminal are first sent to the intelligent load balancer. The intelligent load balancer then sends the received authentication requests to the multimodal authentication request classification module. Based on authentication characteristics, different authentication requests are sent to different container groups within the authentication request classification module, where different container groups perform identity authentication. For example... Figure 2 As shown, the scheduler can specifically include OAuth container group, LDAP container group, ZKP container group, and other container groups. The OAuth container group generates authentication information by verifying user identity and returning a user token. The LDAP container group generates authentication information by verifying username and password and returning authentication status. The ZKP container group generates authentication information by generating a zero-knowledge proof for the user. The task requests associated with the authentication requests are then sent to the automated scheduling module to await task scheduling and execution.

[0031] This invention proposes a task authentication and scheduling method that enables dynamic management of user authentication and resource scheduling in high-performance computing and distributed task cluster environments. It integrates a systematic solution of dynamic authentication and intelligent automated scheduling, overcoming the static coupling bottleneck of authentication logic through the design of several independent container groups within the scheduler. This constructs a hot-swappable authentication system supporting multimodal verification, achieving a more flexible and reliable authentication architecture design. It eliminates authentication failures and efficiency losses caused by single points of failure, thereby optimizing the user's task submission and execution experience and improving computing resource utilization and cluster operational reliability.

[0032] In some embodiments, before assigning an authentication request to a corresponding container group based on the authentication characteristics of the authentication request, the method further includes: Check if the task scheduler's authentication resource pool is in normal working order; If the authentication resource pool is in normal working order, the authentication request will be verified. If the authentication request passes the verification, proceed to the step of assigning the authentication request to the corresponding container group based on the authentication characteristics of the authentication request.

[0033] Understandably, to ensure proper authentication, before sending the authentication request to the corresponding container group for authentication, the working status of the authentication resource pool can be further checked to determine if the authentication resource pool is in a normal working state. Only when the authentication resource pool is in a normal working state will the authentication request be allocated to the corresponding container group for normal authentication. At the same time, when the authentication resource pool is in a normal working state, the authentication request can be further preliminarily evaluated and verified, checking the correctness of the authentication request and other aspects. Only when the authentication request passes the verification will it be allocated to the corresponding container group for normal authentication.

[0034] It should be noted that there are multiple ways to determine whether the authentication resource pool is functioning correctly. This application does not impose any specific limitations here. The normal operation of the authentication resource pool refers to the overall health status of the service within the pool, meaning a check of the scheduler's own health status before authentication to ensure effective authentication after forwarding the authentication request. Specifically, this can be achieved by periodically sending heartbeat signals or other forms of health probes to each component of the authentication resource pool. The intelligent load balancer can also check its own health status before forwarding the authentication request. Only if the intelligent load balancer is functioning correctly can the authentication request be forwarded correctly and authentication be effectively achieved. If the intelligent load balancer or the authentication resource pool is not functioning correctly, or if the authentication request fails verification, an error can be reported directly, and the error reason can be saved. Authentication request verification mainly involves checking the completeness and correctness of the request, such as whether the required fields are complete and the request format is accurate. It can also involve verifying whether the scheduler supports the authentication method corresponding to the request. Based on the authentication request, the corresponding authentication method is determined, and then it is determined from several pre-configured container groups whether a container group supporting that authentication method exists. Ensure that the authentication request is sent accurately and completely to the container group, and guarantee that there exists a container group capable of authenticating the identity of the authentication request.

[0035] Specifically, by checking the authentication resource pool and verifying the authentication request, the scheduler ensures from multiple aspects that the container group can effectively and accurately authenticate the authentication request and its corresponding user, thus guaranteeing the reliable implementation of the authentication process.

[0036] In some embodiments, each container group is bound to a unique corresponding tag; the authentication request is assigned to the corresponding container group based on the authentication characteristics of the authentication request, including: Determine the authentication characteristics of the authentication request; the authentication characteristics include one or more combinations of the authentication method type, security level, and expected processing time of the authentication request. Based on the authentication features of the authentication request, the target tag that matches the authentication request is determined from several tags, and the authentication request is labeled with the target tag. Based on the binding relationship between container groups and tags, authentication requests are assigned to the container group corresponding to the target tag.

[0037] It's easy to understand that the association between authentication requests and corresponding container groups is achieved through tagging. Then, the authentication request is forwarded to the correct container group based on the tag. When a container group is pre-created and registered in the authentication resource pool, a unique tag is configured for each container group based on its type and supported authentication methods. There's a one-to-one correspondence between container groups and tags. When actually allocating authentication requests, the system directly searches for the target tag matching the authentication characteristics of the request and compares it with the tags configured for each container group, thus determining the target container group to which the authentication request should be assigned.

[0038] It should be noted that this application does not impose specific limitations on the specific types and implementation methods of tags. Tags can be designed and configured based on the authentication methods supported by the container group. For example, for several authentication methods that an application needs to support, a corresponding tag can be configured for each, and then the tag can be bound to the container group that supports the corresponding authentication method. Each container group corresponds one tag (representing a type of authentication method). Furthermore, based on authentication method type, security level, expected processing latency, etc., tags can be preset as "ldap", "oauth", "zkp", "highPriority", etc. Tag design can be implemented according to various predefined rules. Correspondingly, the selection of authentication features is also related to the basis used in tag design. For example, if tags are designed and configured based on authentication method classification, the allocation and forwarding of authentication requests will also be based on the authentication method type in the corresponding authentication features, allocating authentication requests of a certain authentication method type to the container group bound to the tag corresponding to that authentication method type. Here, authentication method type refers to the specific means used to implement identity authentication; security level refers to the security strength level that identity authentication needs to achieve; and expected processing latency refers to the time when the user expects the authentication to be completed.

[0039] Specifically, authentication requests can be distributed and forwarded to different container groups directly through label design and label matching, which is simple, effective, and easy to implement.

[0040] In some embodiments, the container group generates authentication information corresponding to the authentication request when the authentication request passes authentication; the task authentication and scheduling method further includes: Identity authentication information is encapsulated and stored using blockchain.

[0041] Understandably, to enhance data security and ensure sufficient security and privacy during the authentication and scheduling process, after any container group completes identity authentication for any authentication request, the authentication information corresponding to the authenticated request will be stored and encapsulated on the blockchain. After verifying the validity of the authentication information, the authentication result will be returned to the user and recorded in the blockchain for subsequent auditing by the administrator console. This application does not impose specific limitations on the specific type and implementation method of the authentication information; various identity credentials and other methods can be used. Similarly, this application does not impose specific limitations on the blockchain and its encapsulation and storage implementation methods; data involved in various authentication processes, such as authentication requests and / or task requests, can be stored on the blockchain, not limited to identity authentication information. Figure 2 As shown, all data output by the authentication request classification module will be stored in the blockchain network and recorded in the block. Administrators can access and manage the blockchain network through the console to audit and access all information.

[0042] Specifically, the design of the blockchain network can provide an effective privacy protection mechanism for data in the authentication process, especially identity authentication information. This avoids the problem of easy leakage caused by directly transmitting identity authentication information back to the user, and avoids authentication failure and efficiency loss due to privacy leaks. It ensures the security and privacy of the authentication process. At the same time, the unified storage of authentication data is achieved by uploading information to the blockchain, which facilitates auditing and tracking, and effectively improves the security and reliability of the entire authentication and scheduling process.

[0043] In some embodiments, the task authentication and scheduling method further includes: Parse the authentication request to obtain the authentication information from it; The authentication information is decrypted so that the container group can use the decrypted authentication information to authenticate the received authentication request.

[0044] It's easy to understand that, to further ensure security, users also undergo preliminary encryption when submitting authentication requests and / or task requests. This primarily involves encrypting the user authentication information submitted in the authentication request. Therefore, after receiving the authentication request and / or task request, the scheduler needs to decrypt the user authentication information before it can perform normal identity authentication. After a user submits an authentication request and / or task request to the scheduler, the identity authentication process is triggered first. This application does not specifically limit the specific type and implementation method of the authentication information in the authentication request; it can be authentication information required for different types and authentication methods, such as user account passwords, OAuth login authorization information, or zero-knowledge proof parameters. This application also does not specifically limit the specific encryption method; various types of encryption algorithms can be used, such as symmetric encryption algorithms, asymmetric encryption algorithms, or hybrid encryption algorithms. Different algorithms can be flexibly selected according to security requirements. In practical applications, users can submit task requests through different terminals. Regardless of which terminal the user submits the task on, the request can undergo preliminary encryption processing on the corresponding terminal.

[0045] Specifically, when submitting a request, the user's identity information is initially encrypted at the terminal submitting the task. This effectively prevents plaintext leakage during transmission, avoids situations such as man-in-the-middle attacks leading to credential leakage, and ensures the security and reliability of the entire authentication and scheduling process.

[0046] In some embodiments, the scheduling queue includes several sub-queues with different priorities; adding the task request associated with the authentication request that has passed authentication to the scheduling queue includes: The task requests associated with the authentication request are added to the corresponding sub-queue based on the authentication method type and / or the priority of the authentication request.

[0047] Understandably, to ensure that important task requests are processed in a timely manner, the scheduling queue in the scheduler can be divided into several sub-queues with different priorities. Different scheduling strategies are configured for sub-queues with different priorities, with higher-priority sub-queues employing preemptive scheduling or other priority scheduling strategies. Therefore, when adding a task request to the scheduling queue, it can be mapped to different sub-queues based on the priority and authentication method type of the task request and its corresponding authentication request. This application does not specifically limit the allocation criteria for task requests to different sub-queues, and is not limited to the authentication method type and / or priority of the authentication request in this embodiment. The corresponding sub-queue can be determined based on authentication characteristics, i.e., the authentication method type, the security level, and the expected processing latency of the authentication request, or directly based on the security, response speed, and urgency of the task request. When verifying an authentication request, the urgency of the authentication request can also be assessed simultaneously based on the scheduler's current load (the density of currently received task requests) and the priority of the corresponding task request to determine the order in which the container group processes the authentication request and which sub-queue the corresponding task request should be added to. The scheduler ultimately schedules and executes all task requests in the entire scheduling queue according to the scheduling strategy corresponding to each sub-queue.

[0048] As a specific implementation, taking a scheduling queue comprising an urgent authentication queue, a normal authentication queue, and a low-priority queue as an example, for task requests associated with authentication requests that have passed identity authentication, all task requests are divided into low-latency high-security authentication tasks, high-latency simplified authentication tasks, and routine load authentication tasks based on their security, response speed, and urgency. Low-latency high-security authentication tasks are added to the urgent authentication queue, high-latency simplified authentication tasks are added to the normal authentication queue, and routine load authentication tasks are added to the low-priority queue. A mapping relationship between task requests and the three sub-queues in the scheduling queue is shown in Table 1. The sub-queue mapping is implemented based on the authentication method corresponding to the task request. Simultaneously, a priority percentage coefficient is configured for each sub-queue as the priority configuration for task scheduling by the scheduler. The larger the priority percentage coefficient, the higher the priority of the sub-queue, and the scheduler prioritizes scheduling and executing task requests in that queue.

[0049] Table 1. Configuration table of the three sub-queues in the scheduling queue

[0050] Furthermore, if the scheduler receives a large number of authentication requests, and a particular container group needs to handle a significant number of authentication requests, a similar queue design can be implemented to manage these requests. For example, a corresponding waiting queue can be designed for each container group, and the order of authentication requests in the waiting queue can be adjusted based on their priority or expected processing latency, thereby adjusting the authentication processing order.

[0051] Specifically, by designing sub-queues with different priorities, the scheduler can flexibly schedule and manage task requests according to the priorities of different sub-queues, ensuring timely response to high-priority tasks and improving scheduling efficiency; and by optimizing the scheduling strategy for authentication services, the normal implementation of authentication and scheduling is guaranteed.

[0052] In some embodiments, the task authentication and scheduling method further includes: For any container group, determine the performance metrics for that container group; the performance metrics include one or more combinations of resource utilization, request load, queue length, and response latency. Adjust the number of container instances created in any container group based on the performance metrics of that container group.

[0053] It's easy to understand that, to achieve efficient scheduling and full utilization of resources in the authentication resource pool, a container group contains several container instances, each capable of independently authenticating an authentication request. Therefore, during task authentication and scheduling, for any container group, the number of container instances created within that group can be adjusted in real-time based on its performance metrics, enabling elastic scaling control of a single container group. The scheduler can collect container group performance metrics, and the elastic control module will then use these metrics to elastically scale the number of container instances within that group. When a container group experiences excessive or persistently high load (e.g., CPU utilization > 85% and task queue length > 100), and receives an excessive number of authentication requests, one or more container instances will be created for that group. Conversely, when a container group experiences excessive or persistently low load (e.g., CPU utilization < 20% and task queue empty), and receives an insufficient number of authentication requests, one or more container instances in that group will be released, reducing resource costs.

[0054] It should be noted that this application does not impose specific limitations on the initial configuration number of container instances in a container group. There are multiple options for the creation and release methods of container instances, and this application does not impose any specific limitations. New container instances can be created by calling cloud platform (private cloud node or public cloud node) APIs (Application Programming Interfaces). After the new container instance starts, its network address, tags, and other information will be registered in the authentication resource pool (e.g., through a service registry such as etcd). After registration, it is then associated with the tag bound to the corresponding container group, thus registering it as a new container instance of that container group. Release can be achieved by directly deleting the association between the instance and the tag bound to the corresponding container group. This application does not impose specific limitations on the performance metrics of container groups, including but not limited to resource utilization, request load, queue length, and response latency in this embodiment, and may also include network traffic. Resource utilization includes CPU (Central Processing Unit) utilization and / or memory utilization, referring to the degree or proportion of authentication resources occupied in the authentication resource pool; request load refers to the amount of request workload handled by the container group per unit time; queue length refers to the number of authentication requests waiting for authentication processing in the waiting queue corresponding to the container group; response latency refers to the time elapsed from sending the request to receiving the response. The performance metrics of each container group can be identified by the corresponding tag of the container group and stored in a specific storage location of the scheduler for further analysis; the performance metrics of several container instances in the same container group can be distinguished by setting a sequence number.

[0055] It should be further noted that this application does not impose any special restrictions on the method for determining the performance indicators of the container group; it can be as follows: Figure 2As shown, a monitoring engine is set up to collect performance metrics of each container instance in each container group in real time or at specified intervals. Then, the elastic scaling module intelligently and dynamically scales up and down the container instance nodes in the container group based on the collected performance metrics, and updates the list of available server nodes in the authentication resource pool in real time. On the other hand, an LSTM (Long Short-Term Memory) time series prediction model can be integrated into the scheduling group to predict the changes in authentication requests to be processed in each container group. For example, an LSTM network can be built using TensorFlow. The LSTM network captures the time series patterns of user login requests in advance, matches the shape of the preprocessed data with the input layer, and then predicts the number of authentication requests in each container group in the future (e.g., the next hour) based on this time series pattern, judging whether there is a surge in authentication requests. Then, the elastic scaling module can adjust the number of container instances created in any container group according to the prediction results, completing machine learning prediction and pre-allocation of authentication resources. By combining the prediction module with the dynamic elastic allocation strategy of container instances in the container group, the authentication resources corresponding to the container group can be scaled up or down in advance, avoiding service delays or request rejections caused by peak loads, and improving the reliability of the authentication process.

[0056] Specifically, by flexibly adjusting the number of container instances in a container group, authentication resources can be dynamically adjusted and allocated. This enables a dynamic authentication process based on dynamic container groups, avoiding unreasonable resource allocation caused by static fixed resource allocation. Dynamic scaling of the container group based on real-time load balancing prevents authentication delays or rejections during high-concurrency authentication requests, minimizing resource waste during container group idle periods and preventing long-term idle authentication resources. By improving dynamic resource allocation and cross-cloud collaboration mechanisms based on real-time load balancing, the cluster can securely and efficiently complete user authentication and resource scheduling in high-concurrency scenarios, eliminating authentication failures and efficiency losses caused by rigid resource configurations, improving resource scheduling efficiency, and achieving cross-environment collaborative authentication.

[0057] In some embodiments, the task authentication and scheduling method further includes: Determine the real-time available resources in the authentication resource pool of the task scheduler; For any container instance in any container group, determine the real-time load of that container instance; Determine the priority coefficient corresponding to the priority of the authentication request currently being processed by any container instance; The first weight is configured based on real-time load; the first weight is positively correlated with the real-time load. The second weight is allocated based on real-time available resources; the second weight is positively correlated with real-time available resources. The third weight is configured based on the priority coefficient; the third weight is positively correlated with the priority coefficient. The sum of the first product, the second product, and the third product is determined as the resource quota allocated to any container instance; wherein, the first product is the product between real-time load and the first weight; the second product is the product between real-time available resources and the second weight; and the third product is the product between the priority coefficient and the third weight.

[0058] Understandably, for any container instance in the container group, resources can be dynamically allocated to individual container instance nodes based on the real-time authentication processing status of the container instance. This is achieved through specific core resource allocation calculations, combined with the real-time load of the container instance node, the available resources in the authentication resource pool, and the priority of authentication requests, dynamically adjusting resource allocation. The resource allocation value R corresponding to a specific container instance node... allocation The specific formula for calculating (i.e., resource quota) is as follows: R allocation =a×S load +b×C resource +c×T priority ; Where a is the first weight, S load Real-time load is the current request workload handled by the container instance; b is the second weight; C resource The current available resources in the authentication resource pool, where c is the third weight, and T... priority This sets the priority of the authentication request currently being processed by the container instance. A container instance node can only handle one authentication request at a time. load C resource and T priority After data collection, all metrics need to be normalized to obtain normalized values ​​for easier calculation. These three metrics are performance indicators of container instances, so elastic control modules, such as the monitoring engine within them, can be reused for data collection. The first, second, and third weights are dynamically adjustable weight coefficients representing the weights of their respective items, which can be adjusted based on the collected metrics. A higher real-time load on a container instance indicates that it needs to allocate more resources to quickly respond to a large number of authentication requests, hence the value of 'a' is larger. Higher real-time available resources in the authentication resource pool indicate that the pool can allocate more resources to container instances, hence the value of 'b' is larger. A higher priority of the authentication requests currently being processed by the container instance indicates that it needs to allocate more resources to quickly respond to high-priority authentication requests, hence the value of 'c' is larger. In practical applications, the scheduler can also adjust the resource allocation value R based on the container instance's corresponding resource allocation value. allocationThe scheduler schedules newly received authentication requests. For example, during a peak period of sudden increase in authentication request access, if the resource allocation value R is increased and the resource allocation value (a) of a container instance node corresponding to a certain authentication method is decreased, the scheduler will tend to reduce the allocation of new authentication requests to such high-load instance nodes and instead schedule new authentication requests to low-load instance nodes. Similarly, when an instance node is under resource pressure, if its resource allocation value (b) is increased and its resource allocation value (a) is decreased, the scheduler will tend to reduce the allocation of new authentication requests to such low-resource-quota instance nodes and instead schedule new authentication requests to instance nodes with high-resource-quota to balance the load and complete the authentication process. allocation As a decision score, it helps the scheduler decide how to schedule new requests, and it can also work with the elasticity control module to determine the scaling up or down of the container group. For example, the resource allocation value R... allocation The higher the level, the more capacity is needed, and the less suitable it is to be allocated to accept new requests.

[0059] Furthermore, the real-time status of the scheduler (such as the processing progress of authentication requests and details of container instance resource usage) and blockchain-based evidence storage information throughout the entire authentication and scheduling process can be transmitted to the administrator console via an interface. This allows administrators to view the entire process data from user authentication requests to user task execution, and to perform operations such as recording and auditing, intervening in authentication requests, and handling anomalies. In addition, authentication logs and permission operations throughout the process can be stored on the blockchain to ensure the protection of the authenticated user's privacy and to achieve tamper-proof authentication audit information.

[0060] Specifically, resource quotas for container instances can be dynamically adjusted based on their specific characteristics, enabling dynamic allocation of authentication resources and avoiding unreasonable resource allocation caused by static fixed resource allocation. Dynamic adjustment of resource quotas and dynamic scaling of container groups can be implemented independently or in a closed-loop manner to effectively prevent authentication delays or rejections during high-concurrency authentication requests, minimize resource waste during container group idle periods, and prevent long-term idle authentication resources. Furthermore, the scheduling queue design can be further configured to prioritize the processing efficiency of highly sensitive tasks, avoid authentication delays caused by resource contention, and automatically avoid node overload or resource idleness. Dynamic allocation of resources in the authentication process eliminates authentication failures and efficiency losses caused by rigid resource configurations, improving resource scheduling efficiency. This can increase authentication throughput several times, save resource costs, achieve zero-latency processing for high-security tasks, and maximize load balancing and resource utilization.

[0061] As a specific embodiment, such as Figure 2As shown, the intelligent load balancer acts as the entry point, responsible for the initial distribution, verification, and tagging of authentication requests. It then forwards the authentication requests to the corresponding container groups and container instances. The various functional modules interact and collaborate, using unique tags to associate authentication request objects with the corresponding container groups and instances. User authentication is performed through the container groups in the authentication request classification module, and the information is stored on the blockchain network. Subsequently, the task cluster scheduling module maps task requests to different priority queues and executes corresponding scheduling strategies based on security, response speed, and urgency. Once the permission scope of a task request is confirmed by the attribute-based permission engine, it can be initiated to respond to the user's request. Simultaneously, during authentication and scheduling, the elastic control module can automatically and flexibly scale container groups dynamically, and the resource allocation engine can automatically adjust the resource quotas of container instances, automatically triggering resource pool updates to ensure efficient resource utilization and improve the flexibility of task scheduling. Ultimately, through the coordinated operation of various functional modules, efficient automation of multi-user authentication and resource scheduling is achieved, forming a logical closed-loop process from performance monitoring to prediction, from task scheduling to allocation, from task execution to auditing. This improves the reliability of the authentication system, reduces the cost of manual intervention, realizes a zero-trust architecture closed loop, and enhances the security, flexibility, and resource utilization of the scheduling system.

[0062] See Figure 3 As shown, Figure 3 This is a schematic diagram of a task scheduler provided in an embodiment of the present invention. To solve the above-mentioned technical problems, an embodiment of the present invention also provides a task scheduler, comprising: Memory 60 is used to store computer program 601; Processor 61 is used to execute computer programs to implement the steps of the aforementioned task authentication and scheduling method.

[0063] The processor 61 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 61 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 61 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 61 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0064] The memory 60 may include one or more computer-readable storage media, which may be non-transitory. The memory 60 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 60 is used to store at least the following computer program 601, which, after being loaded and executed by the processor 61, is capable of implementing the relevant steps of the task authentication and scheduling method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, etc., and the storage method may be temporary storage or permanent storage. The operating system 602 may include Windows, Unix, Linux, etc. The data 603 may include, but is not limited to, the data in the task authentication and scheduling method.

[0065] In some embodiments, the electronic device may further include a display screen 62, an input / output interface 63, a communication interface 64, a power supply 65, and a communication bus 66.

[0066] Those skilled in the art will understand that Figure 3 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0067] For a description of the features in the electronic device provided in the embodiments of the present invention, please refer to the relevant description of the embodiments of the task authentication and scheduling method, which will not be repeated here.

[0068] It is understood that if the task authentication and scheduling methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, magnetic disks, or optical disks, and other media capable of storing program code.

[0069] To address the aforementioned technical problems, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the aforementioned task authentication and scheduling method.

[0070] For a description of the features in the computer-readable storage medium provided in the embodiments of the present invention, please refer to the relevant description of the embodiments of the task authentication and scheduling method, which will not be repeated here.

[0071] To address the aforementioned technical problems, embodiments of the present invention also provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the aforementioned task authentication and scheduling method.

[0072] For a description of the features in the computer program product provided in the embodiments of the present invention, please refer to the relevant description of the embodiments of the task authentication and scheduling method, which will not be repeated here.

[0073] The foregoing has provided a detailed description of a task authentication and scheduling method, a task scheduler, and a storage medium provided by embodiments of the present invention. The various embodiments are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0074] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0075] The above provides a detailed description of the task authentication and scheduling method, task scheduler, and storage medium provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this invention. It should be noted that those skilled in the art can make various improvements and modifications to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of this invention.

Claims

1. A task authentication and scheduling method, characterized in that, Applied to a task scheduler, the task scheduler pre-integrates several container groups; the task authentication and scheduling method includes: If an authentication request is received, the authentication request is assigned to a corresponding container group based on the authentication characteristics of the authentication request; the container group is configured to perform identity authentication on the received authentication request using a preset authentication strategy; Add the task request associated with the authenticated request to the scheduling queue; Based on the request attributes of the task requests, determine whether the operation of each task request is within the permission scope; If the task request is within the authorized scope, the task request will be executed according to the scheduling policy of the scheduling queue.

2. The task authentication and scheduling method according to claim 1, characterized in that, Before allocating the authentication request to the corresponding container group based on the authentication characteristics of the authentication request, the method further includes: Check whether the authentication resource pool of the task scheduler is in normal working order; If the authentication resource pool is in normal working condition, the authentication request is verified; If the authentication request passes the verification, proceed to the step of allocating the authentication request to the corresponding container group based on the authentication features of the authentication request.

3. The task authentication and scheduling method according to claim 1, characterized in that, Each of the container groups is bound to a unique corresponding tag; Based on the authentication characteristics of the authentication request, the authentication request is assigned to the corresponding container group, including: Determine the authentication characteristics of the authentication request; the authentication characteristics include one or more combinations of the authentication method type of the authentication request, the security level of the authentication request, and the expected processing latency of the authentication request; Based on the authentication features of the authentication request, a target tag matching the authentication request is determined from several tags, and the authentication request is labeled with the target tag; Based on the binding relationship between the container group and the tag, the authentication request is assigned to the container group corresponding to the target tag.

4. The task authentication and scheduling method according to claim 1, characterized in that, The container group generates the identity authentication information corresponding to the authentication request when the authentication request passes the identity authentication; The task authentication and scheduling method also includes: The identity authentication information is encapsulated and stored using blockchain technology.

5. The task authentication and scheduling method according to claim 1, characterized in that, Also includes: Parse the authentication request to obtain the authentication information in the authentication request; The authentication information is decrypted so that the container group can perform identity authentication on the received authentication request based on the decrypted authentication information.

6. The task authentication and scheduling method according to claim 1, characterized in that, The scheduling queue includes several sub-queues with different priorities; adding task requests associated with authentication requests that have passed identity verification to the scheduling queue includes: Based on the authentication method type and / or the priority of the authentication request, the task request associated with the authentication request is added to the corresponding sub-queue.

7. The task authentication and scheduling method according to any one of claims 1 to 6, characterized in that, Also includes: For any container group, determine the performance metrics for that container group; the performance metrics include one or more combinations of resource utilization, request load, queue length, and response latency. The number of container instances created in any container group is adjusted based on the performance metrics of that container group.

8. The task authentication and scheduling method according to any one of claims 1 to 6, characterized in that, Also includes: Determine the real-time available resources of the authentication resource pool of the task scheduler; For any container instance in any container group, determine the real-time load of that container instance; Determine the priority coefficient corresponding to the priority of the authentication request currently being processed by any of the container instances; A first weight is configured based on the real-time load; the first weight is positively correlated with the real-time load. A second weight is configured based on the real-time available resources; the second weight is positively correlated with the real-time available resources. A third weight is configured based on the priority coefficient; the third weight is positively correlated with the priority coefficient. The sum of the first product, the second product, and the third product is determined as the resource quota allocated to any container instance; wherein the first product is the product of the real-time load and the first weight; the second product is the product of the real-time available resources and the second weight; and the third product is the product of the priority coefficient and the third weight.

9. A task scheduler, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the task authentication and scheduling method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the task authentication and scheduling method as described in any one of claims 1 to 8.

Images