Controller fragmentation method, electronic equipment, computer storage medium and program product

Abstract

The invention provides a controller fragmentation method, electronic equipment, a computer storage medium and a program product. The method comprises the following steps: the master controller monitors the running states of the plurality of slave controllers; wherein each slave controller is provided with a corresponding fragment label; the main controller obtains a to-be-scheduled custom resource object, wherein the custom resource object is used for describing a user task; the master controller determines a target slave controller from the plurality of slave controllers based on the running state of each slave controller and the attribute of a to-be-scheduled custom resource object; the master controller allocates a fragment label of a target slave controller to the custom resource object to obtain the custom resource object carrying the fragment label; the master controller schedules the custom resource object carrying the fragment label to a target slave controller, so that the target slave controller carries out tuning processing on the custom resource object; therefore, the availability of the system is improved.

Description

Technical Field

[0001] This application relates to the field of cloud-native technology, and in particular to a controller sharding method, electronic device, computer storage medium, and program product. Background Technology

[0002] In Kubernetes (K8s) systems, the controller is the core component for automated management and state tuning. It continuously monitors and adjusts resource objects within the cluster to ensure that the actual state matches the expected state. As K8s applications scale, especially in large-scale clusters and complex business scenarios, the need for managing custom resources increases significantly, posing greater performance and stability challenges to traditional controller architectures. Existing technologies typically rely on fixed sharding or static allocation strategies, lacking the ability to dynamically adapt to the controller's running state and task attributes. When facing high loads, heterogeneous tasks, and uneven resource distribution, this can easily lead to some controllers being overloaded while others are underutilized, impacting overall scheduling efficiency and system responsiveness, and failing to meet the flexible scheduling requirements of large-scale, high-concurrency scenarios. Summary of the Invention

[0003] To address the aforementioned technical problems, embodiments of this application provide a controller fragmentation method, an electronic device, a computer-readable storage medium, and a computer program product.

[0004] The controller fragmentation method provided in this application includes: The master controller monitors the operating status of multiple slave controllers; wherein each slave controller has a corresponding fragmentation tag; The main controller obtains a custom resource object to be scheduled, which is used to describe the user task; The master controller determines the target slave controller from the plurality of slave controllers based on the running status of each slave controller and the attributes of the custom resource object to be scheduled; The main controller assigns the target slave controller's fragment tag to the custom resource object, thereby obtaining a custom resource object carrying the fragment tag; The master controller schedules the custom resource object carrying the fragment tag to the target slave controller, so that the target slave controller can perform tuning processing on the custom resource object.

[0005] The electronic device provided in this application includes a processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program stored in the memory to execute any of the controller slicing methods described above.

[0006] The computer-readable storage medium provided in this application embodiment is used to store a computer program that causes a computer to execute any of the controller fragmentation methods described above.

[0007] The computer program product provided in this application includes computer program instructions that cause a computer to execute any of the controller slicing methods described above.

[0008] In the technical solution of this application embodiment, a master controller monitors the operating status of multiple slave controllers; each slave controller has a corresponding sharding tag; the master controller obtains a custom resource object to be scheduled, which describes a user task; based on the operating status of each slave controller and the attributes of the custom resource object to be scheduled, the master controller determines a target slave controller from the multiple slave controllers; the master controller assigns the sharding tag of the target slave controller to the custom resource object, obtaining a custom resource object carrying the sharding tag; the master controller schedules the custom resource object carrying the sharding tag to the target slave controller, so that the target slave controller can perform tuning processing on the custom resource object; thus, by monitoring the operating status of each slave controller and combining the attributes of the custom resource object in the user task, a suitable slave controller is selected, a corresponding sharding tag is assigned to it, and the task is scheduled to that slave controller. This mechanism can dynamically match tasks with controllers, avoid overloading a single controller, and improve the overall system's load balancing capability and high availability. Simultaneously, since the task is only processed by the slave controller with the corresponding sharding tag, task isolation and fault isolation are achieved, improving system stability. Attached Figure Description

[0009] Figure 1 This is a flowchart illustrating the controller fragmentation method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the controller sharding system architecture provided in the embodiments of this application; Figure 3 This is a schematic diagram of the controller fragmentation management method provided in the embodiments of this application; Figure 4 This is a schematic diagram of the controller fragmentation dynamic fragmentation method provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structural composition of the controller segmentation device provided in the embodiments of this application; Figure 6 This is a schematic structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0010] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0011] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0012] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0013] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0014] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0015] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant national laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0016] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0017] 1) Master Controller: This is the core control unit in the controller cluster. It is responsible for monitoring the running status of all slave controllers, scheduling user tasks to appropriate slave controllers, and dynamically scaling up or down according to system load. The master controller does not directly handle specific tasks but is responsible for overall scheduling and management.

[0018] 2) Slave Controller: refers to one of multiple controller instances managed by the master controller, with each slave controller focusing on tasks for a specific shard tag.

[0019] 3) Shard Tag: This is a tag used to identify the ownership of a user task. It is assigned to a task by the master controller to determine which slave controller should process the task. Different slave controllers correspond to different shard tags, thereby realizing distributed task processing.

[0020] 4) Custom Resource Objects: In the Kubernetes system, users can create custom resource types by defining CRDs (Custom Resource Definitions). Custom resource objects are concrete instances created by users based on these definitions. They typically contain metadata such as task configuration and status information, and are the main carriers of user tasks.

[0021] 5) Reconcile Process: This refers to the process by which the controller automatically adjusts system resources to achieve consistency based on the difference between the desired state and the actual state. The reconcile process is a critical operation performed by the controller to maintain the consistency of user task states.

[0022] In related technologies, Kubernetes controllers are typically deployed as a single instance or a fixed number of replicas, which leads to limited resource scalability, poor fault isolation capabilities, and resource contention issues in multi-tenant scenarios. For example, deploying management controllers in a sharded manner relies on preset sharding strategies, cannot dynamically adjust according to actual load, lacks elastic scaling capabilities, and is difficult to adapt to large-scale, dynamically changing business needs.

[0023] To address the aforementioned issues, this application proposes a controller sharding method. This method involves a master controller monitoring the operational status of multiple slave controllers and dynamically selecting the optimal slave controller and assigning it a corresponding sharding label based on the attributes of custom resource objects in the user task and the load status of the slave controllers. Finally, the task carrying this sharding label is scheduled to the target slave controller for tuning processing. This dynamic sharding mechanism not only achieves high availability for task scheduling but also supports elastic scaling, improving system resource utilization and fairness in multi-tenant scenarios.

[0024] To facilitate understanding of the technical solutions of the embodiments of this application, the technical solutions of this application are described in detail below through specific embodiments. The above-mentioned related technologies are optional solutions and can be arbitrarily combined with the technical solutions of the embodiments of this application, all of which fall within the protection scope of the embodiments of this application. The embodiments of this application include at least some of the following contents.

[0025] The sharding method of the controller cluster provided in the embodiments of this application can be executed by the master controller, which is the core control unit in the controller cluster, responsible for monitoring the operating status of multiple slave controllers and scheduling user tasks to appropriate slave controllers. Figure 1 This is an optional flowchart illustrating a controller cluster sharding method provided in an embodiment of this application. The following will be combined with... Figure 1 The steps shown are explained as follows: Figure 1 As shown, the method includes the following steps 101 to 105: Step 101: The master controller monitors the operating status of multiple slave controllers; each slave controller has a corresponding sharding tag.

[0026] In this embodiment, a controller cluster refers to a distributed control system architecture composed of multiple controller instances. Such a system can improve system high availability, load balancing, and resource utilization. Controller clusters are typically deployed in a Kubernetes (K8s) environment, which supports the management of large-scale custom resource objects.

[0027] In this embodiment, the master controller continuously monitors the status of all slave controllers to ensure that they can respond to and process task requests normally. The master controller is the core control node in the controller cluster, responsible for coordinating and scheduling the entire system's workflow, including task allocation, health checks, metric collection, and elastic scaling decisions. The master controller typically runs on a separate physical or virtual node to ensure its stability and reliability.

[0028] In this embodiment, the slave controller is a working unit in the controller cluster, with each slave controller focusing on processing a specific set of tasks. Distributing tasks across multiple slave controllers effectively avoids single points of failure and improves the overall system's concurrent processing capabilities.

[0029] In some embodiments, the operating status of slave controllers monitored by the master controller typically includes key indicators such as CPU utilization, memory usage, task queue length, and error rate. By using these key indicators, the master controller can determine whether a slave controller is in a healthy state or overloaded.

[0030] In some embodiments, a slave controller refers to one of multiple controller instances managed by a master controller, with each slave controller focusing on handling the first user task for a specific shard label. The slave controllers achieve high availability by using a leader-election mechanism to ensure that only one replica is executing tuning logic at any given time.

[0031] In some embodiments, a sharding tag is a tag used to identify the affiliation of a user task. This tag is assigned to the user task by the master controller to determine which slave controller should process the user task assigned by the master controller. Different slave controllers correspond to different sharding tags, thereby enabling distributed task processing.

[0032] For example, the master controller can periodically retrieve or monitor the metric data of the slave controllers to monitor their operational status in real time. This monitoring mechanism helps the master controller to promptly remove a slave controller from the scheduling scope when it detects an anomaly, or to trigger elastic scaling operations when necessary, thereby ensuring the overall stability and efficiency of the system.

[0033] Step 102: The main controller obtains the custom resource object to be scheduled. The custom resource object is used to describe the user task.

[0034] In this embodiment, when a user submits a task request, the task request is created and stored in the Kubernetes cluster in the form of a custom resource object. A custom resource object is a specific instance created by the user based on a resource type defined by a CRD (Custom Resource Definition). It typically contains metadata such as task configuration and status information and serves as the primary carrier of the user's task. By introducing custom resource objects, the system can support users in defining and managing complex business logic on the Kubernetes platform, such as training and inference tasks and cloud-native application deployments.

[0035] Custom resources, or Kubernetes CRDs, are primarily used to extend the Kubernetes API, allowing users to define and manage the resource types they need. Custom Kubernetes CRDs are designed based on the characteristics of training / inference tasks or cloud-native application tasks. When a user initiates a training / inference task or a cloud-native application task, the corresponding training / inference task or cloud-native application task is created based on the custom resource CRD.

[0036] For example, users can create custom resource objects for the first user task via API or command-line tools. MutatingWebhook will assign an initial sharding tag to the custom resource object of the user task during the creation process for subsequent scheduling. This process not only ensures standardized management of the first user task but also provides basic support for dynamic sharding.

[0037] Step 103: The master controller determines the target slave controller from multiple slave controllers based on the running status of each slave controller and the attributes of the custom resource object to be scheduled.

[0038] In this embodiment, the master controller comprehensively considers the running status of the slave controllers and the attributes of the custom resource objects to select the most suitable slave controller as the target slave controller. The running status of the slave controller includes performance indicators such as CPU, memory, and queue length, while the attributes of the custom resource objects may include fields such as namespace, tags, and annotations. The master controller evaluates the load capacity and suitability of each slave controller based on its running status and the attributes of the custom resource objects, and ultimately determines the most suitable slave controller for handling the current user task.

[0039] For example, the master controller might use round-robin, weighted round-robin, or load balancing strategies to select a target slave controller. For instance, if a slave controller currently has a low load and good responsiveness, the master controller is more likely to select that slave controller to handle the current user task. By employing this selection method, it is possible to effectively prevent some slave controllers from affecting the overall system's response speed and stability due to overload.

[0040] Step 104: The main controller assigns a target fragment tag to the custom resource object and obtains the custom resource object carrying the fragment tag.

[0041] In this embodiment, once the target slave controller is determined, the master controller assigns a corresponding shard label to the custom resource object to be scheduled. This means that the custom resource object to be scheduled will be handled solely by the target slave controller in subsequent processing, and the master controller ensures that the task's ownership is clear and will not conflict with other shards. The master controller completes the shard label assignment by updating the label field of the custom resource object, ensuring that the custom resource object can be correctly identified and scheduled throughout the entire Kubernetes cluster.

[0042] For example, shard label assignment is implemented by the Kubernetes system through the MutatingWebhook component. When a user creates a new custom resource object, the MutatingWebhook component automatically injects a shard label and writes this shard label into the metadata field of the custom resource object corresponding to the user task. In this way, the shard to which the user task belongs can be accurately identified whenever the user task is accessed or scheduled, thus ensuring the accuracy of the scheduling process.

[0043] Step 105: The master controller schedules the custom resource object carrying the fragmentation tag to the target slave controller so that the target slave controller can perform tuning processing on the custom resource object.

[0044] In this embodiment, after the fragmentation label allocation is completed, the master controller schedules the custom resource object carrying the fragmentation label to the target slave controller, thereby enabling the target slave controller to start executing the tuning processing logic. Since the target slave controller only processes user tasks with fragmentation labels matching those of the slave controller, the master controller only needs to schedule the custom resource object carrying the fragmentation label to the corresponding slave controller, without performing any additional filtering or forwarding operations.

[0045] For example, scheduling can be implemented in an event-driven manner, where Kubernetes notifies the controller managing that custom resource object to handle changes when the label of the custom resource object changes. This approach not only improves scheduling efficiency but also reduces unnecessary network overhead and computational resource consumption.

[0046] The controller sharding method provided in this application monitors the operating status of multiple slave controllers by a master controller. Based on the attributes of custom resource objects and the load of the slave controllers, it dynamically selects the optimal slave controller and assigns it a corresponding sharding tag. Finally, the custom resource object carrying the sharding tag is scheduled to the target slave controller for tuning processing. This dynamic sharding mechanism not only achieves high availability for task scheduling but also supports elastic scaling, improving system resource utilization and fairness in multi-tenant scenarios.

[0047] Figure 2 This is an architecture diagram of the controller cluster provided in the embodiments of this application, such as... Figure 2 As shown, the controller cluster includes a master controller and multiple slave controllers. The master controller monitors the running status of the multiple slave controllers. Each slave controller has a corresponding shard label. The process involves: acquiring custom resource objects to be scheduled, which describe user tasks; determining a target slave controller from among the multiple slave controllers based on the running status of each slave controller and the attributes of the custom resource objects to be scheduled; assigning shard labels to the target slave controller for the custom resource objects, resulting in custom resource objects carrying shard labels; scheduling the custom resource objects carrying shard labels to the target slave controller so that the target slave controller can perform tuning processing on the custom resource objects; and multiple slave controllers performing tuning processing on user tasks carrying corresponding shard labels.

[0048] In some embodiments, the main controller includes a processing unit, an allocation unit, and a scheduling unit. For example, the processing unit may be a TaskController, the allocation unit may be a MutatingWebhook admission controller, and the scheduling unit may be a Scheduler.

[0049] In some embodiments, a processing unit performs tuning processing on a custom resource object carrying a master controller tag.

[0050] Here, the processing unit can refer to the TaskController.

[0051] Here, the master controller label is used to mark task objects that the master controller is responsible for processing. Master controller labels typically exist as annotations or labels within Kubernetes resource objects, such as aiops.io / scheduled-shard-id:master. Through this labeling mechanism, the master controller can identify and process only tasks related to it, thereby achieving task classification and isolation.

[0052] There is a logical association between the main controller tag and the main controller itself. Upon startup, the main controller registers a listener that continuously monitors all tasks tagged with the main controller tag and executes specific control logic on these tasks, such as initialization, cache management, and scheduling decisions. This ensures that only tasks meeting specific conditions are processed by the main controller, avoiding conflicts and performance issues caused by mixed tasks.

[0053] For example, when a user creates a new training task or cloud-native application, the system automatically adds a master controller label to the user, ensuring that the master controller takes over the master controller label and performs subsequent scheduling and allocation operations. This approach improves the system's organization and scalability.

[0054] In this embodiment, the type of task processed by the main controller is limited by setting a main controller label. This effectively isolates different types of control logic, thereby reducing concurrency conflicts and further improving system stability and processing efficiency.

[0055] In some embodiments, a fragmentation label is assigned to a custom resource object to be scheduled by an allocation unit.

[0056] Here, the second component can refer to the MutatingWebhook admission controller.

[0057] Here, an allocation unit is an identifier used to assign user tasks to specific slave controllers. Each shard tag corresponds to a slave controller instance, and the format of aiops.io / scheduled-shard-id is typically: <shard-id>The shard-id is a unique identifier for the slave controller. The scheduling system uses a shard label mechanism to dynamically route tasks to different slave controllers, thereby achieving load balancing and elastic scaling. When the master controller receives a task, it assigns an appropriate shard label to the task according to a preset scheduling strategy (such as a static scheduler or a dynamic discovery scheduler). After the shard label is generated, the master controller forwards the task to the corresponding slave controller for further processing.

[0058] For example, suppose a user submits a large-scale machine learning training task. The system can select the most suitable slave controller to assign shard labels to the user's large-scale machine learning training task based on the current load of each slave controller. This ensures that the user's large-scale machine learning training task can be executed efficiently and avoids the situation where a slave controller is overloaded due to too many tasks.

[0059] In this embodiment, by assigning sharding labels to custom resource objects to be scheduled, these user tasks can be reasonably distributed across multiple slave controllers. This distributed task processing improves system throughput and response speed, thereby enhancing the system's resilience and availability.

[0060] In some embodiments, a scheduling unit schedules a custom resource object carrying a sharding tag to the slave controller corresponding to the sharding tag.

[0061] Here, the scheduling unit can refer to the Scheduler. Scheduling mainly includes two modes: StaticScheduler and DynamicScheduler. The scheduling unit is responsible for assigning shard-ids to user-created custom resource objects and scheduling them to the specified slave controllers for sharding and tuning logic.

[0062] In some embodiments, the controller includes a tuning unit for tuning custom resource objects carrying corresponding fragment tags.

[0063] Here, the tuning units included in the controller can be TaskControllers, each of which focuses on processing a specific shard (identified by its shard-id) of the application. The slave controller only starts the TaskController, without enabling other components such as Webhooks or Schedulers.

[0064] Here, tuning refers to a series of control logics executed by the slave controller on user tasks to ensure that the actual state of the user task matches its expected state. The tuning process typically includes functions such as resource allocation, status checks, error recovery, and lifecycle management. The tuning unit, as part of the slave controller, is specifically responsible for executing the tuning logic and making corresponding adjustments based on changes in the user task's state. The slave controller is primarily responsible for receiving tasks and initiating the tuning logic, while the tuning unit focuses on the specific tuning process. This division of responsibilities helps improve code modularity and maintainability, and also facilitates high-availability deployment because each slave controller can run independently and process its own set of tasks.

[0065] For example, each controller runs as a Pod in the Kubernetes cluster, and the leader-election mechanism ensures that only one replica is active at any given time. Through this leader-election mechanism, when a replica fails, one of the other replicas can quickly take over the work of the failed replica, thus ensuring the continuity of task processing.

[0066] In this embodiment, by scheduling tasks to corresponding slave controllers and having them tuned by the tuning unit of the slave controllers, distributed task management and high availability can be achieved. This approach improves system reliability and stability, enabling support for larger-scale task processing needs and ultimately meeting the high-performance requirements of complex business scenarios.

[0067] In summary, in practical implementation, the various steps of the entire embodiment have a clear collaborative relationship. First, the processing unit of the main controller is responsible for identifying and processing user tasks carrying the main controller's tag, ensuring the correct classification and isolation of tasks. Next, the allocation unit of the main controller assigns shard tags to the custom resource objects to be scheduled, realizing task routing and load balancing. Finally, the scheduling unit of the main controller schedules the custom resource objects carrying the shard tags to the slave controllers corresponding to the shard tags, and the tuning unit of the slave controller performs tuning processing to ensure that the user tasks are completed as expected. The entire process realizes closed-loop control from task identification, allocation to execution, improving the stability, resilience and scalability of the system.

[0068] In some embodiments, the scheduling unit of the main controller includes a first scheduler.

[0069] Here, the first scheduler can refer to the static scheduler. The static scheduler can be initialized using the `NewStaticScheduler` function, passing in a predefined list of shards. An instantiated `staticScheduler` structure, containing a `shards` field, stores the predefined list of shards. At startup, the first scheduler logs information displaying the currently available list of shards. During scheduling, the target object is assigned to a random shard. First, it checks if the object has already been assigned a shard; if not, it randomly selects one from the `shards` list and logs it. The `SetScheduledShardID` method sets the selected shard ID to the object. If the `shards` list is empty, it logs that no shards are available.

[0070] Specifically, the main controller implements static scheduling through the first scheduler, including: The main controller starts the first scheduler; The available shard list is obtained through the first scheduler. The available shard list is used to store the slave controllers that are in a healthy state and their corresponding shard labels. The first scheduler determines whether the custom resource object to be scheduled has been assigned a shard label; if not, it selects the target from the list of available shards from the controller. The first scheduler assigns target fragment tags to the custom resource objects to be scheduled from the control of the fragmentation. The first scheduler schedules custom resource objects carrying shard tags to the target slave controller.

[0071] Here, the first scheduler can determine the distribution target of custom resource objects based on a static strategy (such as random selection). As the starting point of the scheduling process, the first scheduler is responsible for initializing the scheduling environment and loading the list of available slave controllers. For example, in a Kubernetes environment, the first scheduler might update the information of available slave controllers in real time by listening for Pod state change events.

[0072] The available shard list is a dynamically maintained data structure that records all running slave controller instances in the system that are available to receive new tasks. Each slave controller typically corresponds to a specific shard-id and is associated with a specific set of task tags. The available shard list is monitored by a system that collects status information (such as CPU utilization, memory usage, queue length, etc.) from each slave controller, ensuring that only healthy slave controllers are added to the list. This allows the primary scheduler to make more reasonable scheduling decisions based on the latest system status, improving the overall efficiency and stability of the system.

[0073] Shard tags are metadata appended to custom resource objects to identify which shard (i.e., which slave controller) should process the custom resource object. The format of aiops.io / scheduled-shard-id= <shard-id>,in <shard-id>This indicates the specific shard number. The first scheduler checks if the shard label exists and if it is empty. If it exists, the first scheduler directly assigns the custom resource object to the corresponding slave controller; if it does not exist or is empty, the first scheduler proceeds to the next step, selecting a target slave controller. This mechanism ensures that the shard allocation logic for the second user task is clear and controllable, preventing custom resource objects from being incorrectly assigned to irrelevant shards. In actual implementation, there is a clear mapping relationship between shard labels and slave controllers. Each shard label uniquely points to one slave controller, thus ensuring the accuracy and efficiency of custom resource object scheduling.

[0074] When a custom resource object is not assigned a shard label, the first scheduler selects a suitable target slave controller from the list of available shards. This selection process can be performed according to different scheduling strategies, such as random selection. Furthermore, the first scheduler can also optimize the selection by considering the current load of the target slave controller (such as queue length and processing rate) to achieve load balancing and maximize resource utilization. For example, if a slave controller currently has a low load, the first scheduler will prioritize selecting this slave controller, thereby improving system response speed.

[0075] After assigning shard labels, the first scheduler updates the metadata of the custom resource object, making the metadata carry the new shard labels. Subsequently, the first scheduler sends the custom resource object to the corresponding target slave controller for tuning. Tuning refers to the target slave controller comparing the expected state of the user task with the current state and taking appropriate actions to ensure consistency between the expected and current states. For example, in Kubernetes, tuning might include creating, updating, or deleting resource objects such as Pods, Services, and Deployments. By accurately assigning custom resource objects to appropriate target slave controllers, the system can achieve efficient resource management and task scheduling while ensuring high availability and consistency of user tasks.

[0076] In summary, this embodiment of the application achieves fine-grained sharding and intelligent scheduling of custom resource objects by introducing a scheduling mechanism of a first scheduler and shard tags. This scheduling mechanism effectively avoids overloading a single slave controller, thereby balancing system load, improving user task processing efficiency, and ultimately enhancing system stability and scalability. In actual implementation, the entire scheduling process is a closed-loop control process. First, the first scheduler initializes the scheduling environment and obtains the currently available shard list. Next, the first scheduler checks whether the custom resource object to be scheduled already has a shard tag. If it does, the first scheduler directly schedules the task; if it does not, the first scheduler selects a suitable target slave controller from the available shard list and assigns the corresponding shard tag to the custom resource object to be scheduled. Finally, the first scheduler sends the custom resource object carrying the shard tag to the target slave controller for tuning. This scheduling process ensures that user tasks are always on the optimal scheduling path throughout their entire lifecycle, thereby improving the overall performance and reliability of the system.

[0077] In some embodiments, the scheduling unit of the main controller includes a second scheduler.

[0078] Here, the second scheduler is a dynamic scheduler, or a dynamic discovery scheduler.

[0079] Specifically, the main controller implements dynamic scheduling through a second scheduler, including: The main controller starts the second scheduler, which contains scheduling policy configuration fields. The available shard list is obtained through the second scheduler. The available shard list is used to store the slave controllers that are in a healthy state and their corresponding shard labels. The second scheduler selects targets from the list of available shards from the controller based on a round-robin strategy. The second scheduler assigns target fragment labels to the custom resource objects to be scheduled from the control of the fragmentation. The second scheduler schedules custom resource objects carrying fragment tags to the target slave controller.

[0080] Here, the second scheduler is the module used to execute dynamic scheduling logic. Its main function is to rationally allocate user tasks to different controller instances (i.e., shards) based on the current system state and resource allocation. The second scheduler supports extensible design; its scheduling capabilities can be enhanced by adding different types of fields, such as load balancing fields, priority fields, and tenant isolation fields. This diversity of fields allows the second scheduler to flexibly adjust scheduling strategies according to actual business needs, improving system response efficiency and fairness. By introducing a second scheduler with multiple fields, more granular task scheduling can be achieved, thereby improving the overall system performance and resource utilization. In multi-tenant or multi-task concurrent scenarios, the system can effectively avoid resource contention and unfairness.

[0081] The available shard list is a data structure used to store information about all available slave controller instances in the current system. Each slave controller represents an independent shard, responsible for handling tuning tasks for a subset of custom resource objects. The available shard list is typically maintained by the master controller and updated periodically to reflect the latest health and availability information. Shard controller information may include metrics such as the node the slave controller is on, resource utilization, task queue length, and runtime. By acquiring and maintaining the available shard list, the system can monitor the working status of each shard in real time, providing accurate data support for subsequent scheduling decisions, thereby improving the accuracy and efficiency of task allocation.

[0082] Round-robin is a classic load balancing algorithm that sequentially selects the next available controller instance as the target. In this step, the next available slave controller is selected from the list of available shards, and tasks are assigned to it. Round-robin ensures that tasks are evenly distributed across multiple available slave controllers, avoiding the problem of some controllers being overloaded while others are idle. Next, the target shard label selected by the round-robin strategy is bound to the specific user task, forming a task object with shard information. This operation is typically accomplished by adding specific key-value pairs to the task object's metadata. For example, in a Kubernetes environment, a label format like `aiops.io / scheduled-shard-id: shard-3` can be used. This label determines which slave controller the task will be scheduled to for processing. By assigning target shard labels to tasks, the system implements a mapping relationship between tasks and shards. The system ensures that tasks are accurately scheduled to the appropriate controller instance, thereby improving its scheduling efficiency and the determinism of task processing.

[0083] Subsequently, the master controller submits the task to the corresponding target slave controller instance based on the fragmentation tag carried by the task. Upon receiving the task, the target slave controller initiates its internal TaskController module, which executes specific tuning logic, such as checking task status, updating resource configurations, and triggering event notifications. This tuning process is the core logic of the entire control system, directly impacting task execution results and system stability. By precisely scheduling tasks to the corresponding target slave controllers and performing tuning, the system can efficiently and reliably manage the task lifecycle, thereby ensuring service continuity and consistency and meeting the high availability requirements of large-scale distributed systems.

[0084] In summary, this embodiment of the application introduces a second scheduler and its various fields, combined with a polling strategy and a sharding label mechanism, to achieve intelligent task scheduling and efficient processing. This embodiment ensures that tasks are evenly distributed among multiple slave controllers, avoids resource contention and task backlog, and further improves the overall throughput and response speed of the system.

[0085] In some embodiments, the second scheduler includes a scheduling policy configuration field, which includes one or more of the following.

[0086] 1) The first field is used to represent a read-write lock, which is used to protect concurrent access to the list of available shards.

[0087] Here, the first field can be represented as `mu`: a read-write lock. A read-write lock is a synchronization mechanism used to control access to shared resources by multiple threads. In this application, the read-write lock is used to protect the shared data structure of the available shard list, preventing data inconsistency caused by multiple threads simultaneously modifying the available shard list. For example, during the runtime of the dynamic scheduler, multiple threads may simultaneously attempt to update the state of the available slave controllers. By using a read-write lock, the system can ensure the atomicity of the operations performed by multiple threads simultaneously attempting to update the state of the available slave controllers. By introducing a read-write lock mechanism into the program, data races and conflicts can be avoided during concurrent access, thereby improving system stability and reliability.

[0088] 2) The second field is used to identify the second scheduler.

[0089] Here, the second field can be represented as `name`: the scheduler name. The name of the second scheduler is an identifier used to uniquely identify different scheduler instances. In a scheduling system, schedulers are typically named as strings for ease of management and monitoring. The example name `dynamic-scheduler-v1.0` can represent a specific version of the dynamic scheduler. By assigning a unique name to each scheduler, logging, status monitoring, and troubleshooting can be easily performed, thereby improving system observability and maintainability.

[0090] 3) The third field is used to indicate the resynchronization period, which indicates the time interval at which the list of available shards is refreshed periodically.

[0091] Here, the third field can be represented as `resyncPeriod`: the resynchronization period. The resynchronization period refers to the time interval at which the scheduler periodically clears and rebuilds the list of available shards. In this application, the scheduler performs resynchronization operations according to the resynchronization period, ensuring that the list of available shards is always up-to-date. For example, if the resynchronization period is set to 30 seconds, the scheduler will check the status of all available slave controllers every 30 seconds and update the health status information of all available slave controllers. By setting a reasonable resynchronization period, failed or unavailable slave controllers can be detected and handled in a timely manner, ensuring the accuracy and real-time performance of scheduling decisions.

[0092] 4) The fourth field indicates the list of available shards, which stores the mapping between available slave controllers and their health status.

[0093] Here, the fourth field can be represented as `candidates`: storing a mapping of available shards and their health status. The available shard list is a data structure used to store information about all currently available slave controllers and their health status. For example, the available shard list might contain data in the following format: `{"shard-1": "healthy", "shard-2": "unhealthy"}`. The available shard list guides the scheduler in assigning tasks to the most suitable slave controller. Through the available shard list, dynamic awareness and management of slave controller status can be achieved, thereby supporting elastic scaling and load balancing, and improving overall performance and stability.

[0094] In practice, there is a correlation between the available shard list and the resource information monitored by the sixth field. When the sixth field detects an increase in resource pressure on a slave controller, it can combine the health status information in the available shard list to decide whether to temporarily remove the slave controller from the scheduling scope, thereby avoiding the allocation of too many tasks to high-load nodes.

[0095] 5) The fifth field is used to represent the atomic counter, which is used to implement the polling strategy.

[0096] Here, the fifth field can be represented as `roundRobinIndex`: an atomic counter used to implement round-robin scheduling. An atomic counter is a thread-safe counter used to implement the index increment operation in the round-robin algorithm. In this application, the atomic counter is used to implement the round-robin strategy, that is, to sequentially select the next available slave controller to allocate tasks. For example, when the scheduler receives a new task request, the scheduler selects a shard based on the value of the atomic counter, and the scheduler increments the atomic counter so that another shard can be selected next time. By using the atomic counter, the fairness and efficiency of the round-robin strategy can be ensured, thereby achieving a uniform distribution of load and avoiding situations where some slave controllers are overloaded while others are idle.

[0097] 6) The sixth field is used to monitor and cache the resource status of multiple slave controllers. The resource status is used to reflect the tuning pressure of the corresponding slave controller.

[0098] Here, the sixth field can be represented as `store` and `informer`: used for listening to and caching Pod resources. The function of the sixth field is to listen to and cache resource information from slave controllers, such as CPU utilization, memory usage, and request latency. By analyzing this resource information, the tuning pressure on the slave controller can be assessed, i.e., the slave controller's current task processing capacity and load. For example, if the CPU utilization of a slave controller is close to 100%, it indicates that the slave controller is under high load, and the scheduler should reduce the number of tasks assigned to that slave controller. By listening to and caching resource information, dynamic awareness of the controller's state can be achieved, thereby optimizing task scheduling strategies and improving system response speed and throughput.

[0099] 7) The seventh field is used to create a new slave controller in response to a fragmentation expansion command, and to delete a specified slave controller in response to a fragmentation shrinkage command.

[0100] Here, the seventh field represents the creation and deletion of Pods: `_createPod` and `_deletePod` execute the creation and deletion operations of Pods on the controller's shards after receiving shard expansion and shrinkage commands from the controller, respectively. The seventh field handles dynamic scaling logic. When the scheduling and control system detects insufficient resources or excessive load, it issues a shard expansion command, triggering the creation of Pods on the controller; conversely, when the system load decreases or resources are abundant, it issues a shard shrinkage command, triggering the deletion of Pods on the controller. By introducing the seventh field, elastic scaling based on actual needs can be achieved, thereby improving resource utilization and system adaptability.

[0101] 8) The eighth field is used to record the shard tag and health status of a new slave controller to the list of available shards when it is added or updated, and to remove a specified slave controller from the list of available shards when it is deleted.

[0102] Here, the eighth field can represent registering and deregistering Pods: `_registerPod` is called when a Pod is added or updated, recording the Pod's shard ID and health status. `unregisterPod` is called when a Pod is deleted, removing the Pod from the candidates. The purpose of the eighth field is to update its status information in the available shard list when a controller changes (such as being added, updated, or deleted). For example, when a new slave controller comes online, its shard tag and health status are automatically recorded in the available shard list; when a slave controller is deleted, its relevant information is removed from the available shard list. This dynamic update mechanism of the eighth field ensures that the available shard list always reflects the latest controller status, improving the accuracy of scheduling decisions and enhancing self-healing capabilities and stability.

[0103] 9) The ninth field is used to clear and rebuild the list of available shards according to the resynchronization cycle.

[0104] Here, the ninth field can represent resynchronization: `resync` periodically clears `candidates` based on `resyncPeriod`, re-registers all Pods, and updates the available shard list. The ninth field is used to set up a scheduled task to periodically clear expired data from the available shard list. For example, shard information that hasn't been updated for a long time can be cleaned up every certain period (e.g., every 5 minutes) to prevent invalid or outdated data from affecting scheduling decisions. This periodic cleanup mechanism using the ninth field maintains the shard list, keeping it simple and effective. This maintenance method prevents scheduling errors caused by data redundancy or errors, thereby improving system reliability and operational efficiency.

[0105] In summary, in this embodiment, by defining scheduling policy configuration fields in the second scheduler, functions such as concurrency control, status monitoring, resource management, and dynamic scaling are implemented. Defining multiple fields in the second scheduler to implement these functions ensures the scheduler can operate efficiently and stably. This approach also allows for dynamic adjustment of the number of shards and task allocation strategies, further improving the overall performance and availability of the system.

[0106] In actual implementation, the above steps cooperate to form a complete scheduling and control system. Specifically, the first field ensures thread safety of the available shard list through read-write locks, enabling the list to be correctly read and updated in a multi-threaded environment; the second field provides a unique identifier for the second scheduler, facilitating subsequent log tracing and debugging; the resynchronization period set in the second field ensures the timeliness of the available shard list; the fourth field, as the core data structure, stores the status information of all available slave controllers; the fifth field implements a polling scheduling strategy, making task allocation more even and reasonable; the sixth field provides a basis for scheduling decisions by monitoring resource usage; the seventh field enables elastic scaling based on load changes, improving the system's ability to handle sudden traffic surges; the eighth field dynamically updates the content of the available shard list, ensuring consistency between the available shard list and the actual controller status; and the ninth field uses a timed cleanup mechanism to prevent expired data from interfering with scheduling decisions. The entire process achieves closed-loop control from status monitoring to scheduling decisions to resource adjustment, improving the system's intelligence level and operational efficiency.

[0107] See Figure 3 , Figure 3 This is a schematic diagram of a dynamic controller fragmentation management method provided in an embodiment of this application.

[0108] In some embodiments, the main controller performs shard management, including: The master controller acquires metric data from each slave controller, which includes one or more of the following: CPU utilization, memory utilization, request processing latency, throughput, error rate, number of concurrent requests, and task queue length. The master controller determines whether to perform a sharding management operation based on the metric data and / or operating status of each slave controller. The sharding management operation includes one or more of the following: task migration, sharding expansion, and sharding reduction.

[0109] Here, the metrics data is a series of performance and status metrics collected during the operation of the Kubernetes controller instance, used to assess the current load and health status of the Kubernetes controller instance.

[0110] CPU and memory utilization: This represents the proportion of CPU and memory resources used by the Pod where the Kubernetes controller instance resides, reflecting the system resource consumption of the Pod where the Kubernetes controller instance resides.

[0111] Request latency: This represents the time interval from receiving a request to completing a response, and is used to measure the response speed of a Kubernetes controller instance.

[0112] Throughput: This represents the number of requests a Kubernetes controller instance can handle per unit of time, reflecting the system's processing capacity.

[0113] Error rate: The ratio of the number of erroneous requests to the total number of requests within a certain period of time, used to measure the stability of the system.

[0114] Concurrent requests: This indicates the number of requests currently being processed. The number of concurrent requests reflects the system's concurrent processing capacity.

[0115] Queue length: Indicates the number of requests waiting to be processed, reflecting the degree of task backlog.

[0116] By regularly collecting these metrics, the master controller can gain a comprehensive understanding of the operational status of each Kubernetes controller instance, providing a basis for subsequent sharding management decisions. For example, when the request latency of a Kubernetes controller instance continues to rise and the number of concurrent requests approaches its limit, it may mean that this Kubernetes controller instance is nearing overload, and the system needs to scale up this Kubernetes controller instance.

[0117] The running status refers to the overall working status of a Kubernetes controller instance, which is typically obtained by the master controller through health checks, heartbeat mechanisms, etc. If a Kubernetes controller instance becomes unresponsive for an extended period, experiences an Out of Memory (OOM) exception, or crashes due to abnormal input, it is considered to be in an unhealthy state.

[0118] Sharding management refers to dynamically adjusting the sharding structure and allocation strategy based on the running status and metrics data of Kubernetes controller instances to optimize overall system performance and reliability. Specific sharding management operations include: task migration, which migrates certain tasks from the current Kubernetes controller instance to other, less busy Kubernetes controller instances. The scheduler implements the migration through load balancing strategies, thereby avoiding task backlog on a single controller instance and improving overall task processing efficiency; sharding scaling, which adds a Kubernetes controller instance Pod to increase the processing capacity of a shard when the system detects that the load on a shard is too high; and reducing unnecessary Kubernetes controller instance Pods when the load on a shard is low and resource utilization is low, thereby saving system resources.

[0119] For example, if the CPU and memory utilization of a Kubernetes controller instance is consistently higher than 90% and the queue length continues to grow, the master controller can determine that the corresponding shard is at risk of overload. Therefore, it will trigger shard expansion and add a new Kubernetes controller instance Pod to the shard to distribute the task pressure and improve the overall system throughput and response speed.

[0120] In some embodiments, the master controller calculates the tuning pressure value of each slave controller; determines whether the number of slave controllers needs to be adjusted based on the tuning pressure value; if the tuning pressure value exceeds a preset expansion threshold, a fragmentation expansion command is issued and the creation unit is called to execute the fragmentation expansion command; if the tuning pressure value is lower than a preset reduction threshold, a fragmentation reduction command is issued and the deletion unit is called to execute the fragmentation reduction command.

[0121] Tuning stress is a quantitative metric used to measure the current load on a slave controller. It assesses whether the slave controller's ability to handle custom resource objects (such as task instances, task versions, etc.) is approaching its limits. Tuning stress is typically calculated based on multiple performance metrics, such as CPU utilization, memory usage, request latency, queue length, throughput, and error rate. These metrics reflect the actual workload and responsiveness of the slave controller when executing tuning logic. By calculating the tuning stress, the operating status of the slave controller can be dynamically monitored, and scaling decisions can be made accordingly.

[0122] For example, in a real system, suppose a slave controller is responsible for managing multiple task instances. When the CPU utilization of the slave controller reaches 90% and the average request latency exceeds a preset threshold, it indicates that the slave controller is already under high load. When the CPU utilization of the slave controller reaches 90% and the average request latency exceeds the preset threshold, the tuning pressure value increases significantly, indicating that the system may need to be expanded to avoid system performance degradation.

[0123] After obtaining the tuning stress value, the system will determine whether to adjust the number of slave controllers based on the set strategy. This determination is typically made by comparing the tuning stress value with a preset threshold range. If the tuning stress value is higher than the expansion threshold, it indicates that the current slave controller resources are insufficient, and new slave controller instances need to be added. Conversely, if the tuning stress value is lower than the reduction threshold, it indicates that the current slave controller resource utilization is low, and reducing some slave controller instances can be considered to optimize resource allocation.

[0124] The scaling threshold is a preset value used to determine when to add new slave controllers. When the tuning pressure exceeds the scaling threshold, it indicates that the current slave controller can no longer effectively handle all tasks, resulting in a performance bottleneck, and therefore the scaling process needs to be initiated. The shard scaling command is generated by the master controller and sent to the scheduler. The scheduler determines on which node to deploy the new slave controller instance based on available resources. The creation unit is responsible for the actual execution of the scaling operation, such as starting a new Pod and registering it to the Kubernetes cluster.

[0125] The scaling-down threshold is also a preset value used to determine when the number of slave controllers can be reduced. When the tuning pressure value is lower than the scaling-down threshold, it indicates that the current slave controller's resource utilization is low, potentially leading to resource waste, thus requiring the scaling-down process to be initiated. The shard scaling-down command is generated by the master controller and sent to the scheduler, which is responsible for selecting appropriate slave controller instances to take offline. The deletion unit is responsible for executing the specific scaling-down operations, such as terminating the specified Pod and updating related configuration information.

[0126] In summary, in this embodiment of the application, by calculating the tuning pressure value of each slave controller and determining whether to perform sharding expansion or reduction operations based on the tuning pressure value of each slave controller, the system can dynamically adjust the number of slave controllers, achieve elastic expansion and reduction, thereby improving the stability and resource utilization of the system and adapting to the load change requirements under different business scenarios.

[0127] In this embodiment, dynamic adjustments to the sharding structure are achieved by collecting and analyzing the operational metrics and status information of Kubernetes controller instances. This allows for the timely detection of potential performance bottlenecks or fault points, enabling flexible operations such as task migration and scaling up / down, thereby improving overall system stability and resource utilization efficiency while ensuring fairness and high availability in multi-tenant scenarios. In summary, this embodiment achieves intelligent decision-making for sharding management by acquiring and analyzing the operational metrics and status of Kubernetes controller instances. This not only improves the system's elasticity and adaptability but also enhances service reliability and the economic efficiency of resource utilization.

[0128] The following is a specific training example of the dynamic partitioning described above.

[0129] See Figure 4 This paper proposes a dynamic sharding mechanism for Kubernetes controllers and its implementation method. Through a sharding strategy, the controller can shard based on certain attributes (such as namespaces, tags, annotations, etc.) of the custom resource objects it manages, ensuring that each shard is responsible for a different set of custom resource objects. Through dynamic scheduling, shards can dynamically adjust themselves to adapt to changes in the number of custom resource objects and resource requirements. Furthermore, each shard can be configured with multiple replicas, and a leader election mechanism ensures that only one replica executes the task, thereby guaranteeing high availability. The overall architecture design of the Kubernetes controller dynamic sharding mechanism is as follows: Figure 4 As shown: The Master Controller is the core of the entire sharding mechanism, responsible for managing and monitoring the status of all shards. The Master Controller enables all necessary components, such as TaskController, MutatingWebhook, Scheduler, and Others. The Master Controller only processes tasks with specific tags (e.g., aiops.scheduling tag(io / scheduled-shard-id): master). The resources contained in these tasks (such as task instances, task versions, and resource trackers) are monitored and cached by the Master Controller.

[0130] The master controller monitors the status of all slave controllers and ensures the healthy operation of each shard through periodic health checks. If the master controller detects a failure in a slave controller, it will automatically reassign the affected tasks to other healthy slave controllers. The master controller is also responsible for collecting metrics from all slave controllers (such as CPU memory usage, request latency, throughput, error rate, concurrent requests, queue length, etc.). These metrics are used to determine whether it is necessary to scale up or down the slave controllers to meet the current system requirements.

[0131] Each slave controller focuses on processing applications whose shards are identified by their shard ID. A slave controller only starts the TaskController and does not enable other components such as Webhooks or Schedulers. Controllers only process applications with tags that match their shard ID (e.g., aiops.io / scheduled-shard-id=). <shard-id>The controller will monitor and cache the resources for these tasks.

[0132] To implement a dynamic fragmentation mechanism for Kubernetes (K8s) controllers, a dynamic fragmentation mechanism and its implementation method are proposed based on the concept of dynamic scaling. The implementation process of the dynamic fragmentation mechanism for K8s controllers is as follows: S401: Start the main controller (including RegisterWebhook, InitControlPlane, and Scheduler).

[0133] RegisterWebhook is used to register task-related WebhookHandlers (ValidatingHandler and MutatingHandler) with the server. RegisterWebhook ensures concurrency safety and path uniqueness, and adds monitoring metrics and logging during the registration process. InitControlPlane is used to initialize the control platform cluster information. Scheduler is used to allocate target objects to an available shard.

[0134] S402: Start the slave controller (including TaskController).

[0135] TaskController writes complex task tuning logic based on custom resource descriptions (CRDs) and manages the lifecycle of custom resource (CR) objects.

[0136] S403: Users initiate tasks (such as creating training inference tasks, cloud-native applications, etc.), and users create custom resource objects for Task.

[0137] S404: MutatingWebhook assigns a shard-id: shard-2, MutatingWebhook to a user-created custom resource object Task.

[0138] S405: The Scheduler primarily includes two modes: StaticScheduler and DynamicScheduler. It is responsible for assigning shard-ids to user-created custom resource objects and scheduling them to the specified slave controller shards with designated tuning logic. Both schedulers implement the Scheduler interface, which mainly contains the Start and Schedule methods. The two schedulers implement these two methods respectively.

[0139] The static scheduler initialization process involves the system creating a static scheduler by calling the `NewStaticScheduler` function, passing in a predefined list of shards. The system then instantiates a `staticScheduler` structure, which contains a field named `shards` to store the predefined list of shards.

[0140] The static scheduler logs when it starts, and the system displays a list of currently available shards.

[0141] The static scheduler assigns a target object to a random shard. First, it checks if the object has already been assigned a shard. If not, it randomly selects a shard from the `shards` list and logs this selection. The `SetScheduledShardID` method sets the selected shard identifier (ID) onto the object. If the `shards` list is empty, it logs that no shards are available.

[0142] The dynamic discovery scheduler initialization process involves calling the NewDynamicScheduler function to create the scheduler, passing in the scheduler's name and resynchronization period. The code logic then executes to instantiate the dynamicScheduler structure, which contains various fields.

[0143] The dynamic discovery scheduler starts listening for Pod resource additions, updates, and deletions, and calls the corresponding registration and deregistration methods. If the resynchronization period is greater than 0, a scheduled task is started to resynchronize.

[0144] The dynamic discovery scheduler returns a list of currently available shards. It selects an available shard based on a round-robin strategy. The target object is assigned to an available shard, and this is logged. If the object has already been assigned a shard or no shard is available, it returns false.

[0145] In summary, on the one hand, the embodiments of this application employ a dynamic sharding mechanism. The controller can shard custom resource objects based on certain attributes (such as namespaces, tags, annotations, etc.), and the system is configured so that each shard is responsible for a different set of custom resource objects. This dynamic sharding mechanism does not require prior human intervention; the controller can automatically adjust sharding according to actual conditions, improving the system's flexibility and adaptability. Through dynamic scheduling, shards can be dynamically adjusted to adapt to changes in the number of custom resource objects and resource requirements. Furthermore, a dynamic sharding management method for the Kubernetes controller is proposed, enabling elastic scaling. Shards can be dynamically adjusted to adapt to changes in the number of custom resource objects and resource requirements. Each shard can have multiple replicas, and a leader-election mechanism ensures that only one replica is active, thus guaranteeing high availability. This elastic scaling capability allows the system to automatically adjust resource allocation according to actual load, improving system performance and resource utilization. On the other hand, it achieves fault isolation and fairness in resource allocation. Through the dynamic sharding mechanism and elastic scaling, faults can be better isolated, ensuring that a failure in a single controller will not affect the operation of the entire system. By dynamically adjusting sharding and resource allocation, fairness in resource allocation can be ensured in multi-tenant scenarios, preventing some users from consuming too many resources and thus affecting the user experience of other users.

[0146] Figure 5 This is a schematic diagram of the structural composition of the controller segmentation device provided in the embodiments of this application, applied to the main controller, such as... Figure 5 As shown, the controller slicing device 500 includes: The monitoring module 501 is used to monitor the operating status of multiple slave controllers; wherein each slave controller has a corresponding fragmentation tag.

[0147] The acquisition module 502 is used to acquire a custom resource object to be scheduled, wherein the custom resource object is used to describe the user task.

[0148] The processing module 503 is used to determine the target slave controller from the plurality of slave controllers based on the running status of each slave controller and the attributes of the custom resource object to be scheduled.

[0149] The allocation module 504 is used to allocate the target slave controller's fragment tag to the custom resource object, thereby obtaining a custom resource object carrying the fragment tag.

[0150] The scheduling module 505 is used to schedule the custom resource object carrying the fragment tag to the target slave controller so that the target slave controller can perform tuning processing on the custom resource object.

[0151] In some implementations, the main controller includes: a processing unit, an allocation unit, and a scheduling unit; wherein, The processing unit performs tuning processing on the custom resource object carrying the main controller tag; The allocation unit assigns fragment tags to the custom resource objects to be scheduled. The scheduling unit schedules the custom resource object carrying the shard label to the slave controller corresponding to the shard label. The slave controller includes a tuning unit, which is used to perform tuning processing on custom resource objects carrying corresponding fragment tags.

[0152] In some implementations, the scheduling unit includes a first scheduler.

[0153] In some implementations, the processing module 503 is further configured to start the first scheduler; the acquisition module 502 is further configured to acquire an available shard list through the first scheduler, the available shard list being used to store slave controllers in a healthy state and their corresponding shard tags; the processing module 503 is further configured to determine through the first scheduler whether the custom resource object to be scheduled has been assigned a shard tag; if not, a target slave controller is selected from the available shard list; the allocation module 504 is further configured to assign the target slave controller's shard tag to the custom resource object to be scheduled through the first scheduler; the scheduling module 505 is further configured to schedule the custom resource object carrying the shard tag to the target slave controller through the first scheduler.

[0154] In some implementations, the scheduling unit includes a second scheduler.

[0155] In some implementations, the processing module 503 is further configured to start the second scheduler, which includes a scheduling policy configuration field; the acquisition module 502 is further configured to acquire an available shard list through the second scheduler, the available shard list being used to store slave controllers in a healthy state and their corresponding shard tags; the processing module 503 is further configured to select a target slave controller from the available shard list through the second scheduler based on a round-robin policy; the allocation module 504 is further configured to allocate the target slave controller's shard tag to the custom resource object to be scheduled through the second scheduler; and the scheduling module 505 is further configured to schedule the custom resource object carrying the shard tag to the target slave controller through the second scheduler.

[0156] In some implementations, the scheduling policy configuration field includes one or more of the following: The first field is used to represent a read-write lock, which is used to protect concurrent access to the list of available shards; The second field is used to identify the second scheduler; The third field is used to indicate the resynchronization period, which indicates the time interval at which the list of available shards is periodically refreshed; The fourth field is used to indicate the list of available shards, which is used to store the mapping relationship between available slave controllers and their health status; The fifth field represents the atomic counter, which is used to implement the polling strategy. The sixth field is used to monitor and cache the resource status of the multiple slave controllers, and the resource status is used to reflect the tuning pressure of the corresponding slave controller; The seventh field is used to create a new slave controller in response to a fragmentation expansion command, and to delete a specified slave controller in response to a fragmentation reduction command. The eighth field is used to record the shard tag and health status of a new slave controller to the list of available shards when a new slave controller is added or updated, and to remove a specified slave controller from the list of available shards when a specified slave controller is deleted. The ninth field is used to clear and rebuild the list of available shards according to the resynchronization cycle.

[0157] In some embodiments, the acquisition module 502 is further configured to acquire metric data for each slave controller, the metric data including one or more of the following: CPU utilization, memory utilization, request processing latency, throughput, error rate, number of concurrent requests, and task queue length; the processing module 503 is further configured to determine whether to perform a sharding management operation based on the metric data and / or operating status of each slave controller, the sharding management operation including one or more of the following: task migration, sharding expansion, and sharding shrinking.

[0158] In some embodiments, the processing module 503 is further configured to calculate the tuning pressure value of each slave controller; determine whether the number of slave controllers needs to be adjusted based on the tuning pressure value; if the tuning pressure value exceeds a preset expansion threshold, issue a fragment expansion command and call the creation unit to execute the fragment expansion command; if the tuning pressure value is lower than a preset reduction threshold, issue a fragment reduction command and call the deletion unit to execute the fragment reduction command.

[0159] Those skilled in the art should understand that Figure 5 The functions of each module in the controller segmentation device shown can be understood by referring to the relevant descriptions of the aforementioned method. Figure 5 The functions of each module in the controller segmentation device shown can be implemented by a program running on the processor or by specific logic circuits.

[0160] Figure 6 This is a schematic structural diagram of an electronic device 600 provided in an embodiment of this application. The electronic device may be a terminal device or a server. Figure 6 The illustrated electronic device 600 includes a processor 610, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0161] Optionally, such as Figure 6 As shown, the electronic device 600 may further include a memory 620. The processor 610 can retrieve and run computer programs from the memory 620 to implement the methods described in the embodiments of this application.

[0162] The memory 620 can be a separate device independent of the processor 610, or it can be integrated into the processor 610.

[0163] Optionally, such as Figure 6 As shown, the electronic device 600 may also include a transceiver 630, which the processor 610 can control to communicate with other devices. Specifically, it can send information or data to other devices or receive information or data sent by other devices.

[0164] The transceiver 630 may include a transmitter and a receiver. The transceiver 630 may further include antennas, and the number of antennas may be one or more.

[0165] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0166] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0167] It should be understood that the above-described memory is exemplary and not a limiting description. For example, the memory in the embodiments of this application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DR RAM), etc. That is to say, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0168] This application also provides a computer-readable storage medium for storing computer programs.

[0169] Optionally, the computer-readable storage medium can be applied to the mobile terminal / terminal device / server in the embodiments of this application, and the computer program causes the computer to execute the corresponding processes implemented by the mobile terminal / terminal device / server in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0170] This application also provides a computer program product, including computer program instructions.

[0171] Optionally, the computer program product can be applied to the server in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the server in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0172] Optionally, the computer program product can be applied to the mobile terminal / terminal device in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the mobile terminal / terminal device in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0173] This application also provides a computer program.

[0174] Optionally, the computer program can be applied to the server in the embodiments of this application. When the computer program is run on the computer, it causes the computer to execute the corresponding processes implemented by the server in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0175] Optionally, the computer program can be applied to the mobile terminal / terminal device in the embodiments of this application. When the computer program is run on a computer, it causes the computer to execute the corresponding processes implemented by the mobile terminal / terminal device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0176] Those skilled in the art will 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, or a combination of computer software and electronic hardware. 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 implementation should not be considered beyond the scope of this application.

[0177] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0178] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0179] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0180] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0181] If the aforementioned functions 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 this application, in essence, or the part that contributes to the prior art, or a portion 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 includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0182] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A controller segmentation method, characterized in that, The method includes: The master controller monitors the operating status of multiple slave controllers; wherein each slave controller has a corresponding fragmentation tag; The main controller obtains a custom resource object to be scheduled, which is used to describe the user task; The master controller determines the target slave controller from the plurality of slave controllers based on the running status of each slave controller and the attributes of the custom resource object to be scheduled; The main controller assigns the target slave controller's fragment tag to the custom resource object, thereby obtaining a custom resource object carrying the fragment tag; The master controller schedules the custom resource object carrying the fragment tag to the target slave controller, so that the target slave controller can perform tuning processing on the custom resource object.

2. The method according to claim 1, characterized in that, The main controller includes: a processing unit, an allocation unit, and a scheduling unit; wherein, The processing unit performs tuning processing on the custom resource object carrying the main controller tag; The allocation unit assigns fragment tags to the custom resource objects to be scheduled. The scheduling unit schedules the custom resource object carrying the shard label to the slave controller corresponding to the shard label. The slave controller includes a tuning unit, which is used to perform tuning processing on custom resource objects carrying corresponding fragment tags.

3. The method according to claim 2, characterized in that, The scheduling unit includes a first scheduler; the method further includes: The main controller starts the first scheduler; The available shard list is obtained through the first scheduler. The available shard list is used to store the slave controllers in a healthy state and their corresponding shard labels. The first scheduler determines whether the custom resource object to be scheduled has been assigned a shard label; if not, it selects a target from the list of available shards from the controller. The first scheduler assigns the target fragment label to the custom resource object to be scheduled. The first scheduler schedules the custom resource object carrying the shard tag to the target slave controller.

4. The method according to claim 2, characterized in that, The scheduling unit includes a second scheduler; the method further includes: The main controller starts the second scheduler, which includes a scheduling policy configuration field. The available shard list is obtained through the second scheduler. The available shard list is used to store the slave controllers in a healthy state and their corresponding shard labels. The second scheduler selects a target from the list of available shards from the controller based on a round-robin strategy. The second scheduler assigns the target fragment label from the control to the custom resource object to be scheduled. The second scheduler schedules the custom resource object carrying the shard tag to the target slave controller.

5. The method according to claim 4, characterized in that, The scheduling policy configuration field includes one or more of the following: The first field is used to represent a read-write lock, which is used to protect concurrent access to the list of available shards; The second field is used to identify the second scheduler; The third field is used to indicate the resynchronization period, which indicates the time interval at which the list of available shards is periodically refreshed; The fourth field is used to indicate the list of available shards, which is used to store the mapping relationship between available slave controllers and their health status; The fifth field represents the atomic counter, which is used to implement the polling strategy. The sixth field is used to monitor and cache the resource status of the multiple slave controllers, and the resource status is used to reflect the tuning pressure of the corresponding slave controller; The seventh field is used to create a new slave controller in response to a fragmentation expansion command, and to delete a specified slave controller in response to a fragmentation reduction command. The eighth field is used to record the shard tag and health status of a new slave controller to the list of available shards when a new slave controller is added or updated, and to remove a specified slave controller from the list of available shards when a specified slave controller is deleted. The ninth field is used to clear and rebuild the list of available shards according to the resynchronization cycle.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: The main controller acquires metric data from each slave controller, which includes one or more of the following: CPU utilization, memory utilization, request processing latency, throughput, error rate, number of concurrent requests, and task queue length. The master controller determines whether to perform a sharding management operation based on the metric data and / or operating status of each slave controller. The sharding management operation includes one or more of the following: task migration, sharding expansion, and sharding reduction.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: The master controller calculates the tuning pressure value for each slave controller; The main controller determines whether the number of slave controllers needs to be adjusted based on the tuning pressure value. If the tuning pressure value exceeds the preset expansion threshold, the main controller issues a segmented expansion command and calls the creation unit to execute the segmented expansion command. If the tuning pressure value is lower than the preset reduction threshold, the main controller issues a segmented reduction instruction and calls the deletion unit to execute the segmented reduction instruction.

8. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method according to any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, It includes computer program instructions that cause a computer to perform the method as described in any one of claims 1 to 7.

Images