Method and device for processing multi-resource pool application, electronic device and storage medium

Abstract

This application discloses processing devices, electronic devices, and storage media for multi-resource pool applications. It primarily constructs a Custom Resource Request (CRD) object to declare multiple workloads across resource pools. It monitors the Kubernetes cluster's API Server to obtain resource object events for the BatchWorkload resource type within the Kubernetes cluster. Upon detecting the creation of a BatchWorkload instance within the Kubernetes cluster, it parses the general workload information and resource pool topology distribution of the detected BatchWorkload, generates the workload for each resource pool, and completes the application operations for all workloads in the resource pool. The embodiments of this application improve the efficiency and reduce the cost of multi-resource pool applications.

Description

Technical Field

[0001] This disclosure relates to the field of Internet technology, and in particular to a processing method and apparatus, electronic device and storage medium for multi-resource pool applications. Background Technology

[0002] With the rapid development of cloud-native technologies, more and more users are migrating their businesses to Kubernetes clusters for unified orchestration and management. However, in some scenarios, the node pools managed by user clusters have distinct geographical distribution attributes, requiring the deployment of the same business system in different regions. First, compute nodes within the same resource pool are labeled with the same tag. Then, the user creates a workload for each resource pool. Workloads in different regions select the corresponding tags for the resource pools using NodeSelectors. When the user submits workloads from multiple resource pools to the Kubernetes cluster, the cluster's management and control components schedule the workloads to the appropriate nodes based on the NodeSelector tags, thus enabling the batch deployment of the same business system across multiple resource pools.

[0003] When users need to deploy the same business system in resource pools distributed across multiple regions, the existing solution requires creating corresponding workloads for each resource pool in turn. On the one hand, apart from a few differences such as the number of replicas and tags, most of the information between the workloads of different resource pools is the same. The existing solution will greatly reduce the efficiency of user deployment and operation and maintenance and increase the working cost. Summary of the Invention

[0004] This disclosure provides a processing method, apparatus, electronic device, and storage medium for multi-resource pool applications. Its main objective is to improve the efficiency and reduce the cost of multi-resource pool applications.

[0005] According to a first aspect of this disclosure, a method for processing multi-resource pool applications is provided, comprising:

[0006] Listen to the API Server of the Kubernetes cluster to obtain resource object events of the BatchWorkload resource type within the Kubernetes cluster. The BatchWorkload resource type is a custom resource type CRD. Multiple workloads across resource pools are declared through this CRD object, including the workLoads field and the regionSpec field. The workLoads field is a general information abstracted from the Deployment or StatefulSet type workloads in the Kubernetes cluster. The regionSpec field is used to declare the topology distribution of the workloads in different resource pools.

[0007] Once a BatchWorkload instance is detected to be created within the Kubernetes cluster, the general workload information and resource pool topology distribution of the detected BatchWorkload are parsed to generate the workload for each resource pool and complete the application operations for all workloads in the resource pool.

[0008] Optionally, parsing the general workload information and resource pool topology distribution of the monitored BatchWorkload object, generating the workload for each resource pool, and completing the application operations for all workloads in the resource pool includes:

[0009] Based on the configuration in workLoads.deploymentSpec or statefulsetSpec of BatchWorkload, generate a general workload template object for the resource pool;

[0010] Based on the general workload template object and the topological distribution of workloads in different resource pools configured in the regionSpec field, a corresponding workload object is automatically generated for each resource pool.

[0011] Based on the workload objects, call the Kubernetes API to submit the creation of the corresponding number of deployment type workload objects to the Kubernetes cluster;

[0012] Based on the nodeSelector tag specified when creating the workload, the application is distributed to worker nodes in different resource pools so that the kubelet component on the corresponding worker node can listen for the application scheduling and start the container to perform the corresponding operation.

[0013] Optionally, after automatically generating a corresponding workload object for each resource pool based on the topological distribution of the workload in different resource pools according to the general workload template object and the regionSpec field, the method further includes:

[0014] The generated workload objects are stored using key-value pairs, where the key is the name of each workload and the value is specific information about each workload.

[0015] Optionally, the method further includes:

[0016] Within the Kubernetes cluster, construct a custom resource type (CRD) called BatchWorkload. Declare general information about a set of workloads in the workLoads field, and declare the topology distribution and replica count of different resource pools in the regionSpec field.

[0017] Optionally, the method further includes:

[0018] When it is necessary to maintain the configuration of the workload, modify the corresponding configuration of the workLoads field and / or regionSpec field under the BatchWorkload object according to the maintenance requirements.

[0019] Optionally, the maintenance includes dynamic scaling of workload replicas. When workload configuration needs maintenance, modifying the corresponding configuration of the `workLoads` field and / or `regionSpec` field under the `BatchWorkload` object according to maintenance requirements includes:

[0020] Periodically collect monitoring data corresponding to the workload on each node of the resource pool;

[0021] Based on the resource target threshold configured for the workload and the monitoring data, calculate the expected number of workload replicas for each resource pool.

[0022] By configuring the upper and lower limits of the number of workload replicas for each resource pool and the expected number of workload replicas for each resource pool, it is determined whether the number of workload replicas for each resource pool needs to be dynamically scaled up or down.

[0023] When it is determined that the number of workload replicas in the resource pool needs to be dynamically scaled up or down, modify the corresponding configuration of the regionSpec field under the BatchWorkload object.

[0024] Optionally, determining whether the number of workload replicas in each resource pool needs to be dynamically scaled up or down based on the upper and lower limits of workload replicas in each resource pool and the expected number of workload replicas corresponding to each resource pool includes:

[0025] If the expected number of replicas of the workload in the resource pool is less than or equal to the minimum number of replicas of the workload in the resource pool, it is determined that there is no need to scale up or down the number of workload replicas in the resource pool.

[0026] If the expected number of replicas for the workload in the resource pool is greater than the minimum number of replicas for the workload but less than the current number of replicas for the workload, then it is determined to reduce the number of replicas for the workload in the resource pool.

[0027] If the expected number of replicas for the workload in the resource pool is greater than the current number of replicas for the workload, then compare the relationship between the expected number of replicas for the workload and the maximum number of replicas for the workload in the resource pool.

[0028] If the expected number of replicas for the resource pool workload does not exceed the maximum number of replicas for the resource pool workload, then the current number of replicas for the resource pool workload is updated to the expected number of replicas for the workload.

[0029] If the expected number of replicas for the workload in the resource pool exceeds the maximum number of replicas for the workload in the resource pool, then the current number of replicas for the workload in the resource pool will be adjusted to the maximum number of replicas for the workload, and the replicas with the difference between the maximum number of replicas for the workload and the expected number of replicas for the workload will be extended to other resource pools with redundant resources, and the replicas extended to other resource pools will be tagged with the original resource pool.

[0030] According to a second aspect of this disclosure, a processing apparatus for a multi-resource pool application is provided, comprising:

[0031] The listening unit is used to listen to the API Server of the Kubernetes cluster and obtain resource object events of the BatchWorkload resource type within the Kubernetes cluster. The BatchWorkload resource type is a custom resource type CRD. Multiple workloads across resource pools are declared through this CRD object, including the workLoads field and the regionSpec field. The workLoads field is a general information abstracted from the Deployment or StatefulSet type workloads in the Kubernetes cluster. The regionSpec field is used to declare the topology distribution of the workloads in different resource pools.

[0032] The operation unit is used to parse the general workload information and resource pool topology distribution of the monitored BatchWorkload object after detecting the creation of a BatchWorkload instance in the Kubernetes cluster, generate the workload of each resource pool, and complete the application operation of all workloads in the resource pool.

[0033] According to a third aspect of this disclosure, an electronic device is provided, comprising:

[0034] At least one processor; and

[0035] A memory communicatively connected to the at least one processor; wherein,

[0036] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method described in the first aspect above.

[0037] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are configured to cause the computer to perform the method described in the first aspect above.

[0038] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0039] The multi-resource pool application processing method disclosed herein listens to the API Server of the Kubernetes cluster to obtain resource object events of the BatchWorkload resource type within the Kubernetes cluster. The BatchWorkload resource type is a custom resource type CRD. Multiple workloads across resource pools are declared through this single CRD object, including the workLoads field and the regionSpec field. The workLoads field is a general information abstracted from the Deployment or StatefulSet type workloads in the Kubernetes cluster. The regionSpec field is used to declare the topology distribution of the workloads in different resource pools. When the creation of a BatchWorkload instance is detected within the Kubernetes cluster, the general workload information and resource pool topology distribution of the detected BatchWorkload are parsed to generate the workloads for each resource pool and complete the application operations for all workloads in the resource pool. Compared to existing technologies, the embodiments of this disclosure abstract existing workloads at a higher level within the Kubernetes cluster, constructing a custom CRD resource structure. This provides a method for declaring multiple cross-region workloads using a single CRD resource, enabling unified orchestration of a group of workloads across multiple resource pools. The constructed CRD configuration information template consists of two parts: `workLoads` and `regionSpec`. These describe general information about existing workloads in the cluster and declare the distribution topology of a group of workloads across different resource pools, respectively. This allows for batch deployment of business systems across resource pools, where a single CRD configuration object can be used to declare and manage a group of cross-resource pool workloads, eliminating the need to maintain workloads for each resource pool individually. By operating on a specific CRD resource within the cluster, the general workload information and resource pool topology of this CRD object are automatically parsed, generating workloads for each resource pool. This completes the batch application operation of all workloads in the resource pool, enabling one-click deployment and maintenance of cross-region applications, improving work efficiency, and reducing costs.

[0040] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0041] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0042] Figure 1 A schematic diagram of the overall system architecture for processing multi-resource pool applications provided in this embodiment of the disclosure;

[0043] Figure 2 A schematic diagram of a processing flow for a multi-resource pool application provided in an embodiment of this disclosure;

[0044] Figure 3 This is a schematic diagram of an automatic scaling-up / scaling process across resource pools in a multi-resource pool application provided in an embodiment of this disclosure.

[0045] Figure 4 A block diagram of a processing apparatus for a multi-resource pool application provided in an embodiment of this disclosure;

[0046] Figure 5 A block diagram of a processing apparatus for another multi-resource pool application provided in an embodiment of this disclosure;

[0047] Figure 6 A block diagram of a processing apparatus for another multi-resource pool application provided in an embodiment of this disclosure;

[0048] Figure 7 A block diagram of a processing apparatus for another multi-resource pool application provided in an embodiment of this disclosure;

[0049] Figure 8 A schematic block diagram of an example electronic device provided for embodiments of this disclosure. Detailed Implementation

[0050] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0051] The following description, with reference to the accompanying drawings, describes the processing, apparatus, electronic devices, and storage media for multi-resource pool applications according to embodiments of the present disclosure.

[0052] To address the aforementioned problems, this invention provides a method for handling multi-resource-pool applications. By constructing a custom CRD resource type within the Kubernetes cluster, a higher level of abstraction is achieved for multiple cross-resource-pool workloads. Users only need a single CRD object to orchestrate and declare multiple sets of workloads across resource pools. Furthermore, a CRD resource management and control component is extended to the Kubernetes cluster to monitor CRD resource objects within the cluster. This component automatically parses the monitored CRD objects and uniformly maintains the lifecycle management and deployment of these cross-resource-pool workloads. The architecture for this multi-resource-pool application processing is as follows: Figure 1 As shown:

[0053] Within the Kubernetes cluster, a custom CRD resource type, BatchWorkload, is constructed to abstract existing workloads. A single BatchWorkload object describes multiple sets of cross-region, multi-replica workloads. The structure of the constructed BatchWorkload object is as follows, primarily consisting of two parts: workLoads and regionSpec. The workLoads field abstracts common information from existing Deployment or StatefulSet type workloads in the Kubernetes cluster, including the container image, volume, and restart policy for this set of services. The regionSpec declares the distribution topology of this set of workloads across different resource pools and supports differentiated configuration of the number of workload replicas for different resource pools.

[0054] In one embodiment of this disclosure, a custom resource type BatchWorkload (CRD) is constructed within the Kubernetes cluster. General information about a set of workloads is declared in the workLoads field, and the topology distribution and replica count of different resource pools are declared in the regionSpec field.

[0055] In this way, when a user needs to deploy a set of business systems across resource pools in batches, the general information of this set of workloads can be declared in the workLoads field, and the topology distribution of different resource pools and the number of workload replicas can be declared in the regionSpec field. The user only needs to maintain this BatchWorkload resource object to manage this set of workloads, instead of maintaining the workloads of each resource pool separately.

[0056] After declaring the CRD resource structure of type BatchWorkload as described above in the Kubernetes cluster, users can write a specific BatchWorkload object based on it, describing the orchestration information of a set of workload containers across resource pools, including container specifications, resource pool distribution, and corresponding replica counts. The BatchWorkload object is then submitted to the cluster's API Server via the kubectl tool or by calling the Kubernetes API interface. The extended CRD control and management module monitors the BatchWorkload resource and provides unified management of the workload lifecycle within the BatchWorkload object.

[0057] For specific unified management, please refer to the following: Figure 2 The method shown is implemented as follows: Figure 2This is a schematic flowchart illustrating the processing of a multi-resource pool application provided in an embodiment of this disclosure. Figure 2 As shown, the method includes the following steps:

[0058] Step 101: Listen to the API Server of the Kubernetes cluster and obtain the resource object event of the BatchWorkload resource type in the Kubernetes cluster. The BatchWorkload resource type is a custom resource type CRD. Multiple workloads across resource pools are declared through this CRD object, including the workLoads field and the regionSpec field. The workLoads field is a general information abstracted from the Deployment or StatefulSet type workloads in the Kubernetes cluster. The regionSpec field is used to declare the topology distribution of the workloads in different resource pools.

[0059] Step 102: After detecting the creation of a BatchWorkload instance in the Kubernetes cluster, parse the general workload information and resource pool topology distribution of the detected BatchWorkload, generate the workload for each resource pool, and complete the application operations for all workloads in the resource pool.

[0060] Furthermore, when a BatchWorkload instance is detected to be created within the Kubernetes cluster, and the general workload information and resource pool topology distribution of the detected BatchWorkload are parsed to generate the workload for each resource pool and complete the application operations for all workloads in the resource pool, the following methods can be used, but are not limited to:

[0061] Based on the configuration in workLoads.deploymentSpec or statefulsetSpec of BatchWorkload, generate a general workload template object for the resource pool;

[0062] 2. Based on the general workload template object and the topological distribution of the workload configured in the regionSpec field across different resource pools, automatically generate a corresponding workload object for each resource pool;

[0063] 3. Based on the workload objects, call the Kubernetes API to submit the creation of the corresponding number of deployment type workload objects to the Kubernetes cluster;

[0064] 4. Based on the nodeSelector tag specified when creating the workload, distribute the application to worker nodes in different resource pools so that the kubelet component on the corresponding worker node can hear that an application has been scheduled and start the container to perform the corresponding operation.

[0065] The method described above, in Figure 1 Under this architecture, the CRD resource management and control module is as follows: Figure 1 As shown, it mainly includes a CRD resource monitoring module, a CRD resource parsing module, a workload management module, and a storage module. Each module executes the methods described above as follows:

[0066] 1) After the CRD control and management module starts, the resource monitoring module will start List-Watch to monitor the cluster's APIServer to obtain resource object events of type BatchWorkload within the cluster, including creation, deletion, and modification events;

[0067] 2) When a BatchWorkload instance is detected to be created in the cluster, the CRD resource parsing module will first generate a general workload template object based on the configuration in workLoads.deploymentSpec or statefulsetSpec of the detected object;

[0068] 3) Based on the template object generated in the previous step, the resource parsing module further generates a complete workload object for each resource pool according to the topological distribution of the workload configured in the regionSpec field across different resource pools. The name field, which uniquely identifies the generated workload within the cluster, is appended with the name of each resource pool. For example, in the BatchWorkload example from step 1, the CRD control and management module will generate two Deployment resource objects, app-suzhou and app-guangzhou, within the cluster. app-suzhou has 2 replicas, and app-guangzhou has 3 replicas. The nodeSelector is the name of the corresponding resource pool.

[0069] 4) The resource resolution module notifies the workload module to create the actual workload. The workload management module calls the Kubernetes API to submit two workload objects of type app-suzhou and app-guangzhou to the cluster respectively.

[0070] 5) All worker nodes in the cluster are tagged with their respective resource pools when they are connected. The cluster scheduling component distributes the application to worker nodes in different resource pools according to the nodeSelector tag specified when the CRD control management module creates the workload.

[0071] 6) Once the kubelet component on the corresponding worker node detects that an application has been scheduled, the kubelet component will immediately start the container.

[0072] In some embodiments of this disclosure, after automatically generating a corresponding workload object for each resource pool based on the topological distribution of the workload in different resource pools according to the general workload template object and the regionSpec field, the method further includes:

[0073] The generated workload objects are stored using key-value pairs, where the key is the name of each workload and the value is specific information about each workload.

[0074] Based on this description, the resource resolution module stores the generated workload objects in the internal storage module. The storage module uses key-value pairs, where the key is the name of each workload and the value is the specific information of each workload. Since the name of a BatchWorkload object is always unique when it is created, and the name of the workload generated from the BatchWorkload object is the BatchWorkload name plus the resource pool name as a suffix, the names of all generated workloads are also unique.

[0075] Furthermore, in the embodiments of this disclosure, when it is necessary to maintain the configuration of the workload, the corresponding configurations of the workLoads field and / or regionSpec field under the BatchWorkload object are modified according to the maintenance requirements. Specifically, when it is necessary to maintain the configuration of the workload, such as upgrading the image / scaling up or down, this proposal only requires modifying the corresponding configurations of workLoads / regionSpec under the corresponding BatchWorkload object to trigger the BatchWorkload modification event.

[0076] The CRD control and management module retrieves all workloads from the internal storage based on the BatchWorkload name and updates the new configuration to the workloads under each node pool via the API Server. Users do not need to maintain a large number of Deployments or StatefulSet workloads; they only need to maintain a single CRD object, and the CRD control and management module can automatically complete the one-click upgrade configuration and scaling of multi-resource pool workloads.

[0077] Furthermore, this embodiment supports automatic dynamic scaling of service replicas across resource pools based on actual business traffic in different resource pools. The CRD declaration template supports dynamic scaling strategy configuration, allowing specification of the monitored resource type (resourceName), maximum number of replicas (maxReplicas), minimum number of replicas (minReplicas), and the target threshold for triggering automatic scaling (target). The custom CRD resource type `BatchWorkload` supports configuring the `regionSpec.autoScale` field to declare a group of workloads across resource pools that require automatic dynamic scaling of workload replicas across resource pools based on monitored business traffic, CPU, memory, and other resource usage as specified by `autoScale.resourceName`. Figure 3 As shown.

[0078] The maintenance includes the dynamic scaling of workload replicas. When it is necessary to maintain the configuration of the workload, and to modify the corresponding configuration of the workLoads field and / or regionSpec field under the BatchWorkload object according to the maintenance requirements, the following methods can be used, but are not limited to:

[0079] 1. Periodically collect monitoring data corresponding to the workload on each node of the resource pool;

[0080] 2. Based on the resource target threshold configured for the workload and the monitoring data, calculate the expected number of workload replicas for each resource pool;

[0081] 3. By configuring the upper and lower limits of the number of workload replicas for each resource pool and the expected number of workload replicas for each resource pool, determine whether the number of workload replicas for each resource pool needs to be dynamically scaled up or down.

[0082] 4. When it is determined that the number of workload replicas in the resource pool needs to be dynamically scaled up or down, modify the corresponding configuration of the regionSpec field under the BatchWorkload object.

[0083] Furthermore, determining whether the number of workload replicas in each resource pool needs dynamic scaling by using the upper and lower limits of workload replicas for each resource pool and the expected number of workload replicas for each resource pool can be implemented using, but is not limited to, the following methods:

[0084] 1) If the expected number of replicas of the workload in the resource pool is less than or equal to the minimum number of replicas of the workload in the resource pool, it is determined that there is no need to scale up or down the number of replicas of the workload in the resource pool.

[0085] 2) If the expected number of replicas for the workload in the resource pool is greater than the minimum number of replicas for the workload but less than the current number of replicas for the workload, determine to reduce the number of replicas for the workload in the resource pool.

[0086] 3) If the expected number of replicas for the workload in the resource pool is greater than the current number of replicas for the workload, then compare the relationship between the expected number of replicas for the workload and the maximum number of replicas for the workload in the resource pool.

[0087] 4) If the expected number of replicas for the resource pool workload does not exceed the maximum number of replicas for the resource pool workload, then update the current number of replicas for the resource pool workload to the expected number of replicas for the workload.

[0088] 5) If the number of expected workload replicas in the resource pool exceeds the maximum number of workload replicas in the resource pool, the current number of workload replicas in the resource pool is adjusted to the maximum number of workload replicas, and the replicas with the difference between the maximum number of workload replicas and the expected number of workload replicas are extended to other resource pools with redundant resources. The replicas extended to other resource pools are tagged with the resource pool mentioned above.

[0089] As described above, the metric server component of the Kubernetes cluster periodically collects monitoring data corresponding to the workload on each node of the resource pool. The CRD resource monitoring module then obtains this monitoring data through the API Server.

[0090] The CRD resource monitoring module calculates the expected number of replicas for each resource pool based on the resource target threshold configured for the workload:

[0091] replicas expect =∑resource monitor / target

[0092] Among them, replicas expect This is the expected number of replicas in the current resource pool, ∑resourcemonitor It is the sum of the resource monitoring metrics corresponding to all replicas of the current resource pool workload, and target is the monitoring resource target threshold configured in the CRD.

[0093] By supporting the configuration of the upper and lower limits of replicas for each resource pool, the CRD ensures that the number of replicas of the workload in each resource pool meets the basic work requirements. Classify whether dynamic scaling is required for the current workload in each resource pool according to the configuration:

[0094] 1) No scaling:

[0095] The desired number of replicas is less than the minimum number of replicas replicas expect < minReplicas; the expected value is equal to the current number of replicas replicas expect = replicas current ;

[0096] 2) Scaling down:

[0097] The desired number of replicas is between the minimum and the current number of replicas minReplicas < replicas expect < replicas current ;

[0098] 3) Scaling up:

[0099] The desired number of replicas is greater than the current number of replicas replicas expect > replicas current 。

[0100] Among them, the scaling-down operation is that the CRD resource management control module dynamically updates the number of replicas of the workload in the corresponding resource pool to the calculated desired number of replicas replicas expect 。

[0101] The scaling-up operation needs to be further classified:

[0102] When replicas current < replicas expect ≤ maxReplicas: Similar to the scaling-down operation, since the desired number of replicas does not exceed the set maximum number of replicas, the CRD resource management control module directly updates the number of replicas of the workload in the corresponding resource pool to the desired number of replicas replicas expect 。

[0103] When replicas expectmaxReplicas: Different resource pools may face random business traffic peaks, causing the number of replicas expected in the current resource pool to exceed the set maximum value. On the other hand, other resource pools may still have idle resources. Therefore, in this scenario, the excess expected replicas will be dynamically expanded to other resource pools to improve resource utilization and solve the problem that the current resource pool cannot support more replicas during peak business periods.

[0104] Furthermore, dynamically scaling up excess expected replicas to other resource pools can be achieved using, but is not limited to, the following methods:

[0105] first step:

[0106] Calculate the difference between the current replica and the node's largest replica (replicas). delta =replicas expect -maxReplicas;

[0107] Step 2: Adjust the number of replicas for the current resource pool workload to the maximum value, maxReplicas;

[0108] Step 3: Iterate through other resource pools and calculate the number of redundant replicas of this workload in other resource pools: replicas remain =maxReplicas-replicas current Sort the replicas calculated in step 1 in descending order. delta The number of replicas is based on the number of replicas. remain The resource pools corresponding to the descending queue are expanded sequentially. Replicas that cannot be handled by the current resource pool are expanded to other resource pools with redundant resources.

[0109] Step 4: Tag the replicas extended to other resource pools with the label of this resource pool. Subsequent services, such as load balancers corresponding to the workload of the current resource pool, can access the working replicas extended to other resource pools through this label.

[0110] It should be noted that the embodiments of this disclosure may include multiple steps. For ease of description, these steps are numbered, but these numbers are not a limitation on the execution time slots or execution order between the steps; these steps can be implemented in any order, and the embodiments of this disclosure do not limit this.

[0111] In the embodiments disclosed herein, the API Server of the Kubernetes cluster is monitored to obtain resource object events of the BatchWorkload resource type within the Kubernetes cluster. The BatchWorkload resource type is a custom resource type CRD. Multiple workloads across resource pools are declared through this single CRD object, including the workLoads field and the regionSpec field. The workLoads field is a general information abstracted from the Deployment or StatefulSet type workloads in the Kubernetes cluster. The regionSpec field is used to declare the topology distribution of the workloads in different resource pools. When the creation of a BatchWorkload instance is detected within the Kubernetes cluster, the general workload information and resource pool topology distribution of the detected BatchWorkload are parsed to generate the workloads for each resource pool and complete the application operations for all workloads in the resource pool. Compared to existing technologies, the embodiments of this disclosure abstract existing workloads at a higher level within the Kubernetes cluster, constructing a custom CRD resource structure. This provides a method for declaring multiple cross-region workloads using a single CRD resource, enabling unified orchestration of a group of workloads across multiple resource pools. The constructed CRD configuration information template consists of two parts: `workLoads` and `regionSpec`. These describe general information about existing workloads in the cluster and declare the distribution topology of a group of workloads across different resource pools, respectively. This allows for batch deployment of business systems across resource pools, where a single CRD configuration object can be used to declare and manage a group of cross-resource pool workloads, eliminating the need to maintain workloads for each resource pool individually. By operating on a specific CRD resource within the cluster, the general workload information and resource pool topology of this CRD object are automatically parsed, generating workloads for each resource pool. This completes the batch application operation of all workloads in the resource pool, enabling one-click deployment and maintenance of cross-region applications, improving work efficiency, and reducing costs.

[0112] This invention also proposes a processing apparatus for multi-resource pool applications. Since the apparatus embodiments of this invention correspond to the method embodiments described above, details not disclosed in the apparatus embodiments can be referred to in the method embodiments described above, and will not be repeated here.

[0113] Figure 4 A processing apparatus for a multi-resource pool application provided in this disclosure includes:

[0114] The listening unit 201 is used to listen to the API Server of the Kubernetes cluster and obtain resource object events of the BatchWorkload resource type in the Kubernetes cluster. The BatchWorkload resource type is a custom resource type CRD. Multiple workloads across resource pools are declared through this CRD object, including the workLoads field and the regionSpec field. The workLoads field is a general information abstracted from the Deployment or StatefulSet type workloads in the Kubernetes cluster. The regionSpec field is used to declare the topology distribution of the workloads in different resource pools.

[0115] The operation unit 202 is used to parse the general workload information and resource pool topology distribution of the monitored BatchWorkload object after it is detected that a BatchWorkload instance has been created in the Kubernetes cluster, generate the workload of each resource pool, and complete the application operation of all workloads in the resource pool.

[0116] Furthermore, in one possible implementation of this embodiment, the operation unit 202 includes:

[0117] The parsing module is used to parse the general workload information and resource pool topology distribution of the monitored BatchWorkload objects, generate the workload for each resource pool, and complete the application operations for all workloads in the resource pool, including:

[0118] The first generation module is used to generate a general workload template object for the resource pool based on the configuration in workLoads.deploymentSpec or statefulsetSpec in BatchWorkload.

[0119] The second generation module is used to automatically generate a corresponding workload object for each resource pool based on the general workload template object and the topological distribution of the workload configured in the regionSpec field in different resource pools.

[0120] The first sending module is used to call the Kubernetes API according to the workload object and submit the creation of a corresponding number of deployment type workload objects to the Kubernetes cluster respectively.

[0121] The second sending module is used to distribute the application to worker nodes of different resource pools according to the nodeSelector tag specified when creating the workload, so that the kubelet component on the corresponding worker node can hear that an application has been scheduled and the kubelet component will start the container to perform the corresponding operation.

[0122] Furthermore, the processing device for the multi-resource pool application, such as Figure 5 As shown, it includes storage unit 203.

[0123] The storage unit 203 is used to automatically generate a corresponding workload object for each resource pool based on the topological distribution of the workload configured in the general workload template object and the regionSpec field in different resource pools, and then store the generated workload object using key-value pairs, wherein the key of the key-value pair is the name of each workload, and the value is the specific information of each workload.

[0124] Furthermore, the processing device for the multi-resource pool application, such as Figure 6 As shown, it also includes building unit 204:

[0125] The construction unit 204 is used to construct a CRD custom resource type BatchWorkload resource type within the Kubernetes cluster, declare a set of general information about workloads in the workLoads field, and declare the topology distribution and replica count of different resource pools in the regionSpec field.

[0126] Furthermore, the processing device for the multi-resource pool application, such as Figure 7 As shown, it also includes an update unit 205:

[0127] The update unit 205 is used to modify the corresponding configuration of the workLoads field and / or regionSpec field under the BatchWorkload object according to the maintenance requirements when the configuration of the workload needs to be maintained.

[0128] The maintenance includes the dynamic scaling of workload replicas. When workload configuration needs maintenance, modifying the corresponding configuration of the workLoads field and / or regionSpec field under the BatchWorkload object according to maintenance requirements includes:

[0129] Periodically collect monitoring data corresponding to the workload on each node of the resource pool;

[0130] Based on the resource target threshold configured for the workload and the monitoring data, calculate the expected number of workload replicas for each resource pool.

[0131] By configuring the upper and lower limits of the number of workload replicas for each resource pool and the expected number of workload replicas for each resource pool, it is determined whether the number of workload replicas for each resource pool needs to be dynamically scaled up or down.

[0132] When it is determined that the number of workload replicas in the resource pool needs to be dynamically scaled up or down, modify the corresponding configuration of the regionSpec field under the BatchWorkload object.

[0133] The step of determining whether the number of workload replicas in each resource pool needs to be dynamically scaled up or down based on the upper and lower limits of the workload replicas in each resource pool and the expected number of workload replicas for each resource pool includes:

[0134] If the expected number of replicas of the workload in the resource pool is less than or equal to the minimum number of replicas of the workload in the resource pool, it is determined that there is no need to scale up or down the number of workload replicas in the resource pool.

[0135] If the expected number of replicas for the workload in the resource pool is greater than the minimum number of replicas for the workload but less than the current number of replicas for the workload, then it is determined to reduce the number of replicas for the workload in the resource pool.

[0136] If the expected number of replicas for the workload in the resource pool is greater than the current number of replicas for the workload, then compare the relationship between the expected number of replicas for the workload and the maximum number of replicas for the workload in the resource pool.

[0137] If the expected number of replicas for the resource pool workload does not exceed the maximum number of replicas for the resource pool workload, then the current number of replicas for the resource pool workload is updated to the expected number of replicas for the workload.

[0138] If the expected number of replicas for the workload in the resource pool exceeds the maximum number of replicas for the workload in the resource pool, then the current number of replicas for the workload in the resource pool will be adjusted to the maximum number of replicas for the workload, and the replicas with the difference between the maximum number of replicas for the workload and the expected number of replicas for the workload will be extended to other resource pools with redundant resources, and the replicas extended to other resource pools will be tagged with the original resource pool.

[0139] It should be noted that the foregoing explanation of the method embodiments also applies to the apparatus of this embodiment, and the principle is the same, so it is not limited in this embodiment.

[0140] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0141] Figure 8 A schematic block diagram of an example electronic device 300 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0142] like Figure 8 As shown, device 300 includes a computing unit 301, which can perform various appropriate actions and processes based on a computer program stored in ROM (Read-Only Memory) 302 or a computer program loaded from storage unit 308 into RAM (Random Access Memory) 303. RAM 303 can also store various programs and data required for the operation of device 300. The computing unit 301, ROM 302, and RAM 303 are interconnected via bus 304. I / O (Input / Output) interface 305 is also connected to bus 304.

[0143] Multiple components in device 300 are connected to I / O interface 305, including: input unit 306, such as keyboard, mouse, etc.; output unit 307, such as various types of monitors, speakers, etc.; storage unit 308, such as disk, optical disk, etc.; and communication unit 309, such as network card, modem, wireless transceiver, etc. Communication unit 309 allows device 300 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0144] The computing unit 301 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 301 include, but are not limited to, CPUs (Central Processing Units), GPUs (Graphics Processing Units), various special-purpose AI (Artificial Intelligence) computing chips, various computing units running machine learning model algorithms, DSPs (Digital Signal Processors), and any suitable processor, controller, microcontroller, etc. The computing unit 301 performs the various methods and processes described above, such as the processing of multi-resource pool applications. For example, in some embodiments, the processing of multi-resource pool applications may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 308. In some embodiments, part or all of the computer program may be loaded and / or installed on device 300 via ROM 302 and / or communication unit 309. When the computer program is loaded into RAM 303 and executed by the computing unit 301, one or more steps of the methods described above may be performed. Alternatively, in other embodiments, computing unit 301 may be configured to perform the aforementioned multi-resource pool application processing by any other suitable means (e.g., by means of firmware).

[0145] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, FPGAs (Field Programmable Gate Arrays), ASICs (Application-Specific Integrated Circuits), ASSPs (Application-Specific Standard Products), SOCs (System-on-Chips), CPLDs (Complex Programmable Logic Devices), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0146] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0147] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, EPROM (Electrically Programmable Read-Only Memory) or flash memory, optical fiber, CD-ROM (Compact Disc Read-Only Memory), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0148] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (Cathode-Ray Tube) or LCD (Liquid Crystal Display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0149] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include LANs (Local Area Networks), WANs (Wide Area Networks), the Internet, and blockchain networks.

[0150] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service ecosystem, addressing the shortcomings of traditional physical hosts and VPS (Virtual Private Server, or simply "VPS") services, such as high management difficulty and weak business scalability. Servers can also be servers for distributed systems or servers incorporating blockchain technology.

[0151] It's important to note that artificial intelligence (AI) is the study of enabling computers to simulate certain human thought processes and intelligent behaviors (such as learning, reasoning, thinking, and planning). It encompasses both hardware and software technologies. AI hardware technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, and big data processing. AI software technologies primarily include computer vision, speech recognition, natural language processing, machine learning / deep learning, big data processing, and knowledge graph technologies.

[0152] The various numerical designations such as "first," "second," etc., used in this disclosure are merely for ease of description and are not intended to limit the scope of the embodiments of this disclosure, nor do they indicate a sequential order.

[0153] At least one of the features described in this disclosure can also be described as one or more, and multiple features can be two, three, four or more, and this disclosure does not impose any limitations. In the embodiments of this disclosure, for a technical feature, the technical features in that technical feature are distinguished by "first", "second", "third", "A", "B", "C" and "D", etc., and there is no sequential order or size order among the technical features described by "first", "second", "third", "A", "B", "C" and "D".

[0154] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0155] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A processing method for multi-resource pool applications, characterized in that, include: Listen to the API Server of the Kubernetes cluster to obtain resource object events of the BatchWorkload resource type within the Kubernetes cluster. The BatchWorkload resource type is a custom resource type CRD. Multiple workloads across resource pools are declared through this CRD object, including the workLoads field and the regionSpec field. The workLoads field is a general information abstracted from the Deployment or StatefulSet type workloads in the Kubernetes cluster. The regionSpec field is used to declare the topology distribution of the workloads in different resource pools. Once a BatchWorkload instance is detected to be created within the Kubernetes cluster, the general workload information and resource pool topology distribution of the detected BatchWorkload are parsed to generate the workload for each resource pool and complete the application operations for all workloads in the resource pool.

2. The method of claim 1, wherein, The process involves parsing the general workload information and resource pool topology distribution of the monitored BatchWorkload objects, generating workloads for each resource pool, and completing the application operations for all workloads in the resource pools, including: Based on the configuration in workLoads.deploymentSpec or statefulsetSpec of BatchWorkload, generate a general workload template object for the resource pool; Based on the general workload template object and the topological distribution of workloads in different resource pools configured in the regionSpec field, a corresponding workload object is automatically generated for each resource pool. Based on the workload objects, call the Kubernetes API to submit the creation of the corresponding number of deployment type workload objects to the Kubernetes cluster; Based on the nodeSelector tag specified when creating the workload, the application is distributed to worker nodes in different resource pools so that the kubelet component on the corresponding worker node can listen for the application scheduling and start the container to perform the corresponding operation.

3. The method according to claim 2, characterized in that, After automatically generating a corresponding workload object for each resource pool based on the topological distribution of the workloads configured in the regionSpec field according to the general workload template object, the process also includes: The generated workload objects are stored using key-value pairs, where the key is the name of each workload and the value is specific information about each workload.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: Within the Kubernetes cluster, construct a custom resource type (CRD) called BatchWorkload. Declare general information about a set of workloads in the workLoads field, and declare the topology distribution and replica count of different resource pools in the regionSpec field.

5. The method according to any one of claims 4, characterized in that, The method further includes: When it is necessary to maintain the configuration of the workload, modify the corresponding configuration of the workLoads field and / or regionSpec field under the BatchWorkload object according to the maintenance requirements.

6. The method of claim 5, wherein, The maintenance includes the dynamic scaling of workload replicas. When workload configuration needs maintenance, modifying the corresponding configuration of the workLoads field and / or regionSpec field under the BatchWorkload object according to maintenance requirements includes: Periodically collect monitoring data corresponding to the workload on each node of the resource pool; Based on the resource target threshold configured for the workload and the monitoring data, calculate the expected number of workload replicas for each resource pool. By configuring the upper and lower limits of the number of workload replicas for each resource pool and the expected number of workload replicas for each resource pool, it is determined whether the number of workload replicas for each resource pool needs to be dynamically scaled up or down. When it is determined that the number of workload replicas in the resource pool needs to be dynamically scaled up or down, modify the corresponding configuration of the regionSpec field under the BatchWorkload object.

7. The method of claim 6, wherein, The step of determining whether the number of workload replicas in each resource pool needs to be dynamically scaled up or down based on the upper and lower limits of the workload replicas in each resource pool and the expected number of workload replicas for each resource pool includes: If the expected number of replicas of the workload in the resource pool is less than or equal to the minimum number of replicas of the workload in the resource pool, it is determined that there is no need to scale up or down the number of workload replicas in the resource pool. If the expected number of replicas for the workload in the resource pool is greater than the minimum number of replicas for the workload but less than the current number of replicas for the workload, then it is determined to reduce the number of replicas for the workload in the resource pool. If the expected number of replicas for the workload in the resource pool is greater than the current number of replicas for the workload, then compare the relationship between the expected number of replicas for the workload and the maximum number of replicas for the workload in the resource pool. If the expected number of replicas for the resource pool workload does not exceed the maximum number of replicas for the resource pool workload, then the current number of replicas for the resource pool workload is updated to the expected number of replicas for the workload. If the expected number of replicas for the workload in the resource pool exceeds the maximum number of replicas for the workload in the resource pool, then the current number of replicas for the workload in the resource pool is adjusted to the maximum number of replicas for the workload, and the replicas with the difference between the maximum number of replicas for the workload and the expected number of replicas for the workload are extended to other resource pools with redundant resources, and the replicas extended to other resource pools are tagged with the resource pool.

8. A processing device for a multi-resource pool application, the processing device comprising: include: The listening unit is used to listen to the API Server of the Kubernetes cluster and obtain resource object events of the BatchWorkload resource type within the Kubernetes cluster. The BatchWorkload resource type is a custom resource type CRD. Multiple workloads across resource pools are declared through this CRD object, including the workLoads field and the regionSpec field. The workLoads field is a general information abstracted from the Deployment or StatefulSet type workloads in the Kubernetes cluster. The regionSpec field is used to declare the topology distribution of the workloads in different resource pools. The operation unit is used to parse the general workload information and resource pool topology distribution of the monitored BatchWorkload object after detecting the creation of a BatchWorkload instance in the Kubernetes cluster, generate the workload of each resource pool, and complete the application operation of all workloads in the resource pool.

9. An electronic device, comprising: include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

Images