Container group distribution adjusting method and device, electronic equipment and readable storage medium

Abstract

The embodiment of the invention provides a container group distribution adjusting method and device, electronic equipment and a readable storage medium. The method comprises the steps that a service list and adjusting demand information are acquired; the service list comprises at least one service and adjustment sequence information corresponding to each service; an adjustment task corresponding to each service is created on the service management platform, and the adjustment task is configured to sequentially adjust the container group distribution of the at least one service according to the adjustment demand information and the adjustment sequence information; in the process that the adjustment task is executed, an elastic configuration option of a first service in the service list is closed, and the first service is configured with a first elastic strategy in a preset time period; the elastic configuration option is a switch for controlling the service to execute a first elastic strategy, and when the elastic configuration option is closed, the first service stops executing the first elastic strategy within a preset time period; the first elastic strategy is an automatic container group management rule configured by the service management platform for the first service.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information processing, and in particular to a container group distribution adjustment method and device, electronic equipment and readable storage medium. BACKGROUND

[0002] Currently, under the Kubernetes federation cluster management architecture, administrators achieve maximum resource utilization and minimum cost by dynamically adjusting container group distribution, and use elastic strategies such as timing strategies or monitoring index strategies to cope with changes in business traffic.

[0003] However, there is a conflict between the container group distribution adjustment task and the elastic strategy. When the elastic strategy takes effect, it may directly override the results of the adjustment task, resulting in adjustment failure or deviation from the expectation. For example, a timing strategy may be triggered before the adjustment task is completed, resulting in a discrepancy between the number of container groups and the target.

[0004] Therefore, there is an urgent need for a mechanism to coordinate the execution of container group distribution adjustment and elastic strategies to ensure the controllability and stability of the adjustment process. SUMMARY

[0005] The purpose of the embodiments of the present application is to provide a container group distribution adjustment method and device, electronic equipment and readable storage medium, which can ensure the controllability and stability of the adjustment process. The specific technical solutions are as follows:

[0006] In a first aspect of the present application, a container group distribution adjustment method is first provided, comprising:

[0007] obtaining a service list and adjustment requirement information; the service list includes at least one service and adjustment order information corresponding to each service;

[0008] creating an adjustment task corresponding to each service on a service management platform, the adjustment task being configured to adjust the container group distribution of at least one service in turn according to the adjustment requirement information and the adjustment order information;

[0009] During the execution of the adjustment task, the elastic configuration option of a first service in the service list is closed, and the first service is configured with a first elastic strategy in a preset time period; the elastic configuration option is a switch that controls the execution of the first elastic strategy of the service, and when the elastic configuration option is closed, the first service stops executing the first elastic strategy in the preset time period; the first elastic strategy is an automatic container group management rule configured by the service management platform for the first service.

[0010] In a second aspect of the present application, a container group distribution adjustment device is also provided, comprising:

[0011] an obtaining module, configured to obtain a service list and adjustment requirement information, the service list comprising at least one service and adjustment sequence information corresponding to each service;

[0012] a creating module, configured to create an adjustment task corresponding to each service on a service management platform, the adjustment task being configured to sequentially adjust container group distribution of at least one service according to the adjustment requirement information and the adjustment sequence information;

[0013] a closing module, configured to close an elastic configuration option of a first service in the service list during execution of the adjustment task, the first service being configured with a first elastic policy within a preset time period; the elastic configuration option being a switch for controlling execution of the first elastic policy of the service, when the elastic configuration option is closed, the first service stops executing the first elastic policy within the preset time period; and the first elastic policy being an automatic container group management rule configured by the service management platform for the first service.

[0014] In another aspect of the embodiments of the present application, a computer readable storage medium is also provided, which stores instructions, and when the instructions are run on a computer, the computer is caused to perform the data forwarding method described above.

[0015] In another aspect of the embodiments of the present application, a computer program product comprising instructions is also provided, and when the instructions are run on a computer, the computer is caused to perform the container group distribution adjustment method described above.

[0016] The embodiment of the application acquires a service list and adjustment demand information; the service list includes at least one service and adjustment order information corresponding to each service, which can clearly indicate which services need to be adjusted, and the specific content and order of adjustment, ensuring that the adjustment process is clear and orderly. The service management platform creates an adjustment task corresponding to each service, and the adjustment task is configured to sequentially adjust the container group distribution of at least one service according to the adjustment demand information and the adjustment order information, so that the service can be adjusted in order, and the container group distribution of each service can be optimized according to the demand. During the execution of the adjustment task, the elastic configuration option of the first service in the service list is closed, the elastic configuration option is a switch for controlling the execution of the first elastic policy, the first service is configured with the first elastic policy in a preset time period, and the first elastic policy is an automatic container group management rule configured by the service management platform for the first service. Since the first elastic policy dynamically adjusts the container group quantity of the first service, if the first elastic policy is triggered during the execution of the adjustment task, the container group distribution of the first service may be automatically adjusted. When the elastic configuration option is closed, the service will stop executing the first elastic policy in the preset time period, so that the service will not automatically adjust the container group distribution due to the first elastic policy in the preset time period, and the controllability and stability of the adjustment process are ensured. BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description.

[0018] Figure 1 is a schematic diagram of a container group distribution adjustment architecture provided by the embodiment of the application;

[0019] Figure 2 is an interactive flowchart of a container group distribution adjustment method provided by the embodiment of the application;

[0020] Figure 3 is a flowchart of a container group distribution adjustment method provided by the embodiment of the application;

[0021] Figure 4 is a schematic diagram of an information display device structure provided by the embodiment of the application;

[0022] Figure 5 is a schematic diagram of the hardware structure of an electronic device provided by the embodiment of the application. DETAILED DESCRIPTION

[0023] The technical solutions in the embodiments of the application will be described below with reference to the drawings in the embodiments of the application.

[0024] The container group distribution adjustment method provided by the embodiments of the present application can be applied to at least the following application scenarios, which are described below.

[0025] With the expansion of Kubernetes (K8s) cluster size, in order to maximize resource utilization and minimize cost, a federated cluster architecture is usually adopted. Under the federated cluster architecture, multiple physical clusters are managed as a unified logical cluster, and users only perceive the existence of the logical cluster when using it, without needing to know the details of the underlying physical cluster.

[0026] In this architecture, administrators can dynamically adjust the distribution of container groups according to actual needs, for example: when a physical cluster is no longer used, such as cluster A, the administrator can gradually migrate the container groups from cluster A to other clusters, such as cluster B, without the need for user involvement in operation and maintenance work. This process ensures the flexible use of cluster resources and the smooth running of services.

[0027] In addition, in order to fully utilize the elastic expansion characteristics of public clouds, services are usually configured with elasticity policies to adapt to different business scenario needs. Elasticity policy refers to the automatic resource management mechanism configured by the service management platform for the service based on the elastic expansion capability of the public cloud, and the purpose is to enable the number or distribution of container groups to be dynamically adjusted according to business load, time rules or preset conditions, in order to optimize resource utilization and quickly respond to traffic fluctuations.

[0028] Elasticity policy is a set of automatic resource management rules configured by the service management platform for the service, relying on the elastic expansion capability of the public cloud, and the purpose is to match business load by dynamically adjusting the number or distribution of container groups, to achieve a balance between resource efficiency, cost control and service stability.

[0029] Elasticity policy is composed of trigger conditions and operation actions, and the trigger conditions include time-driven, index-driven and plan-driven; the operation actions include scaling up, scaling down and cross-cluster migration.

[0030] The use of elasticity policy is reflected in three scenarios: first, to cope with predictable periodic traffic such as e-commerce promotions, through timing strategies to pre-scale and scale down; second, to respond to real-time sudden loads such as social platform hot events, based on index-driven strategies for quick adjustment; third, to support planned resource adjustments such as service upgrades and cost optimization, through pre-planned execution of migration or replica number changes.

[0031] Common elasticity policies include:

[0032] Timing strategy: suitable for scenarios with periodic resource usage, such as regular class time peaks in the education industry;

[0033] Monitoring index strategy: suitable for sudden traffic and typical periodic traffic scenarios, such as the Internet and gaming industries;

[0034] Hybrid elasticity strategy: Applicable to scenarios with both periodic resource demands and the need to cope with sudden traffic bursts. It is often used in complex business scenarios in the Internet industry.

[0035] In the federated cluster management architecture, nodes, container groups, and clusters are closely linked. A node is a physical server or virtual host that provides CPU, memory, and other resources to the cluster and serves as the cluster's infrastructure unit. A container group is the smallest unit of service deployment, running on a node and relying on node resources to complete tasks. A node can host multiple container groups, which are assigned to specific nodes using scheduling policies.

[0036] The relationship between nodes and clusters is one of individual and collective. A cluster is a resource pool composed of multiple nodes, managed and scheduled uniformly through orchestration tools. Nodes are part of a cluster, and clusters manage nodes by categorizing them using tags. Administrators can adjust node roles or quantities, dynamically changing cluster resource capacity.

[0037] A container group is a scheduling unit distributed across clusters. A federated cluster, a logical collection of multiple independent clusters, controls the cross-cluster scheduling of container groups. By migrating container groups, you can free up underloaded node resources, reduce or decommission physical clusters, and balance load across multiple clusters. This optimizes resources, improves resource utilization, reduces costs, and ensures high service availability.

[0038] Currently, under the federated cluster management architecture, administrators achieve the following goals by dynamically adjusting the distribution of container groups: releasing some low-load or idle node resources to improve resource utilization; reducing or taking down unnecessary physical clusters to reduce costs; balancing the load across multiple clusters and optimizing resource allocation to ensure high service availability.

[0039] At the same time, service elasticity strategies have become an integral part of cloud-native architectures. Through elasticity strategies, services can dynamically adjust the number of container groups based on business needs to meet the load demands of periodic traffic changes or sudden traffic bursts, thereby avoiding resource waste or service unavailability.

[0040] Container group distribution adjustments and service elasticity policies may conflict in federated cluster management, as shown below:

[0041] Conflict between the scheduled policy and the container group adjustment task: When a scheduled elastic policy is set for a service, the adjustment task may be interfered with by the elastic adjustment. For example: the scheduled policy configured in the service defines the operations to be performed within a specific time period (10:00-11:00), that is, the number of container groups in cluster A is automatically reduced from 20 to 10 through the elastic policy, which belongs to the target state of the scheduled policy and is an adjustment action pre-defined in the policy rules. The scheduled start time of the container group distribution adjustment task is 09:30, and the actual number of container groups in cluster A is 20; the administrator executes the container group distribution adjustment task at 09:50 to migrate the container group from cluster A to cluster B, and the adjustment target is that the number of container groups in cluster A is 10 and the number of container groups in cluster B is 10;

[0042] However, when the 10:00 timing policy takes effect, since the timing policy usually operates on the total number of container groups for the entire service, the total number of service container groups will be forcibly reduced to 10 when it takes effect at 10:00. All container groups are rescheduled by modifying the Deployment resources. The container group adjustment task is to gradually migrate the container groups of cluster A to cluster B through migration operations to achieve the goal of 10 container groups in clusters A and B. The total number of copies may change temporarily during the migration process. When the timing policy is triggered at 10:00, the Kubernetes scheduler deploys 10 container groups to cluster A by default, causing the number of container groups in cluster B to return to zero, causing the container group adjustment task to fail because it cannot achieve the allocation target of cluster B.

[0043] Conflict between the expansion policy and the container group adjustment task: When a service is configured with an expansion policy, the container group adjustment task may also be affected. For example, a service is configured with a scheduled policy between 10:00 AM and 11:00 AM. The service's scheduled policy defines an operation to be executed between 10:00 AM and 11:00 AM, namely, using an elastic policy to expand the number of container groups in cluster A to 20. The container group distribution adjustment task is scheduled to start at 9:30 AM. At 9:30 AM, cluster A actually has only 10 container groups. At 9:50 AM, the administrator initiates a scheduled task to migrate the container groups from cluster A to cluster B, aiming to achieve a distribution state of 5 container groups in cluster A and 5 container groups in cluster B by 10:00 AM. However, the service's scheduled policy automatically expands the number of container groups in cluster A to 20 between 10:00 AM and 11:00 AM. When the 10:00 AM scheduled policy takes effect, it ignores the intermediate state achieved by the scheduled task and directly creates a new container group in cluster A, adjusting the number of container groups deployed in cluster A to 15. This resulted in the failure to achieve the originally planned goal of deploying 5 container groups in cluster A, and cluster B also failed to obtain the expected number of adjusted container groups.

[0044] The key to this problem is that the expansion strategy conflicts with the execution logic of the container group adjustment task. The expansion strategy usually operates on the number of container groups of the entire service. When it takes effect at 10:00, it will forcibly expand the number of container groups of the A cluster to 20, automatically trigger the creation and scheduling of new container groups by modifying the configuration information. The container group adjustment task is to migrate the container groups of the A cluster to the B cluster to achieve the goal of 5 container groups in each of the A and B clusters by migration. During the migration process, the total number of replicas remains unchanged. When the expansion strategy is triggered at 10:00, an additional container group will be created in the A cluster. At this time, if the adjustment task has not been completed, the actual number of container groups in the A cluster may be expanded to 15, far exceeding the planned 5, resulting in a deviation of the adjustment result from the expectation, and the container group adjustment task fails to achieve the goal.

[0045] The current container group distribution adjustment task and the elasticity strategy run independently, and there is no clear coordination mechanism between the two. When the elasticity strategy takes effect, it may directly override the results of the container group distribution adjustment, causing the adjustment task to fail or deviate from the expectation. The execution time of the elasticity strategy and the container group adjustment task may overlap, and the two cannot perceive the state of each other in real time. For example, when the timing strategy is about to take effect, the adjustment task fails to complete in time, or the result of the adjustment task is not perceived by the elasticity strategy in time, ultimately leading to the conflict and failure of the task.

[0046] Based on the above application scenarios, the adjustment method of the container group distribution provided by the embodiments of the present application is described below.

[0047] Figure 1 A schematic diagram of an adjustment architecture of a container group distribution provided by an embodiment of the present application.

[0048] The container group distribution adjustment device 100 is a tool or mechanism for migrating container groups between different physical K8s clusters. According to factors such as resource utilization, cost, geographical location, etc., a container group migration strategy is formulated. The container groups are migrated from one physical cluster to another physical cluster while ensuring the continuity of the service. Ensure that the state and configuration information of the container group can be correctly synchronized to the target cluster during the migration process. By dynamically adjusting the container group distribution, the resource utilization is optimized, the cost is reduced, and the flexibility and scalability of the cluster are improved.

[0049] Service management platform 200: is the core component in the federal cluster management architecture, responsible for unified management of service elasticity policy, adjustment task and container group distribution information. Abstract multiple physical clusters into a unified logical cluster, users only need to interact with the logical cluster, without worrying about the details of the underlying physical cluster. The main functions of service management platform 200 include: supporting users to configure service elasticity policy, starting service elasticity policy and closing service elasticity policy. Create, issue and store adjustment tasks to ensure that container group distribution is optimized according to demand.

[0050] Unified logical cluster 400: abstract multiple physical clusters into a logical cluster, providing unified API and interface. Specifically, an interface or API can be provided to support users to configure and modify the elasticity policy of the service, and to issue the elasticity policy to the unified logical cluster to ensure that the policy takes effect in all physical clusters. Receive service list and adjustment demand information generated by the adjustment service recommendation device. Create and issue adjustment tasks to the logical cluster to ensure that the container group distribution is optimized according to the adjustment demand. Store the state, execution result and history record of the adjustment task for easy query.

[0051] Among them, starting the service elasticity policy means re-enabling the service elasticity policy after the end of the preset time period, so that the service can dynamically adjust the number of container groups according to the elasticity configuration to cope with load changes. Specifically, in the service management platform, the elasticity configuration option of the target service can be enabled through API or interface operation. Restore the automatic expansion and reduction capability of the service to ensure that the service can dynamically adapt to load changes.

[0052] Closing the service elasticity policy means disabling the service elasticity policy within a preset time period to keep the current number of container groups stable and not affected by the elasticity event. The purpose of closing the service elasticity policy is to avoid the interference of the elasticity policy on the adjustment task when adjusting the container group distribution. Specifically, in the service management platform, the elasticity configuration option can be automatically triggered to close through a preset automated script or timing task at a specific time period, ensuring that the number of container groups of the service remains unchanged within the preset time period. Avoid triggering the elasticity policy during the execution of the adjustment task to reduce the interference of the adjustment task. Ensure that the number of container groups remains stable during the adjustment process, and improve the success rate of the adjustment task.

[0053] Adjustment service recommendation device 300: an intelligent recommendation system that recommends a list of services suitable for migration based on user's historical configuration of elasticity policy and real-time monitoring data. The goal is to select services that are less likely to trigger an elasticity event when adjusting the container group distribution, thereby reducing the interference with the adjustment task.

[0054] Specifically, the user's historical configuration of the elasticity policy can be obtained from the service management platform, the central processing unit (CPU) usage and queries per second (QPS) data of the service can be obtained from the monitoring system, the historical CPU and historical QPS data are analyzed, and the load regularity and elasticity event triggering condition of the service are identified. Based on the historical data and real-time monitoring data, the load change of the service in the future period of time is predicted. Services that will not trigger an elasticity event in the current time period are filtered out, for example, services with stable load and not reaching the elasticity policy triggering threshold.

[0055] In order to filter out services that are highly unlikely to trigger an elasticity event, the following steps can be implemented:

[0056] First, the elasticity policy configured by the service is obtained from the service management platform, including the timing automatic adjustment policy and the policy based on monitoring indicators. At the same time, historical CPU usage, historical QPS data and other data of the service are collected from the monitoring system, the load regularity of the service is analyzed, such as whether the load is stable, the frequency of triggering elasticity adjustment in the past, and the size relationship between the current indicator data and the elasticity threshold, such as whether the current CPU usage is lower than the elasticity threshold triggering expansion.

[0057] Then, for the timing policy, check whether the adjustment task time overlaps with the execution time of the timing policy. If it overlaps, the service has a high risk of triggering an elasticity event and needs to be excluded. For the policy based on indicators, use historical load data to predict the load change in the future period of time. If the predicted value exceeds the threshold, the service has a high risk of triggering an elasticity event; if the current load plus the historical fluctuation range is still far below the threshold, the service has a low risk of triggering an elasticity event.

[0058] When sorting, the service with the lowest risk is selected first, followed by the service with low resource utilization, to reduce the impact of adjustment on business, and finally the business importance is considered, and the non-core business service is adjusted first.

[0059] According to the priority of the service, the resource usage and the business importance, a recommended service list is generated. The recommended service list is sent to the service management platform as an input of the container group distribution adjustment task. The conflict between the adjustment task and the elasticity policy is reduced, and the success rate of the adjustment task is improved. Through intelligent recommendation of the service list, the operation and maintenance complexity can be reduced, and manual intervention can be reduced.

[0060] Unified logical cluster 400: A mechanism that unifies multiple physical K8s clusters and presents them as a single logical cluster. Users manage multiple physical clusters through a unified API or control plane. Container groups are distributed to different physical clusters according to policies. Load balancing and failover across clusters improve application availability. Unified logical cluster simplifies multi-cluster management, improves resource utilization and application disaster recovery capabilities.

[0061] Kubernetes cluster: An open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. A K8s cluster is a collection of physical or virtual nodes that run containerized applications together. According to user-defined configurations, automatically deploy containerized applications to nodes in the cluster. Automatically scale the number of application instances based on load. Monitor application status to ensure it always runs in the desired state. K8s cluster is the infrastructure for running containerized applications, improving resource utilization and simplifying operations.

[0062] Container group: The smallest deployment unit in Kubernetes, consisting of one or more containers. Containers in a container group share network namespaces, storage volumes, and other resources. Container groups may be scheduled, restarted, or deleted. Container groups are the basic unit of application running in Kubernetes, allowing related containers to be combined to simplify application deployment and management.

[0063] Deployment is an object in Kubernetes that defines the deployment and update strategy of a container group. Users define the desired state of the application through Deployment, and Kubernetes automatically ensures that the actual state is consistent with the desired state. When updating the application, Deployment will gradually replace the old container group to ensure service continuity. When a container group or node fails, Deployment will automatically create a new container group to replace the failed instance. Deployment is the core object in Kubernetes for managing stateless applications, simplifying application deployment, updating, and maintenance.

[0064] Figure 2 Figure 1 is an interaction flow diagram of a container group distribution adjustment method provided by an embodiment of the present application, as shown in Figure 1, and specifically as follows: Figure 2

[0065] Step 201: The container group distribution adjustment device 100 sends a service list request message to the adjustment service recommendation device 300;

[0066] ​The container group distribution adjustment device 100 sends a request for obtaining a service list to prepare for subsequent operations such as resource adjustment based on the service list.

[0067] Step 202: The service recommendation adjustment device 300 collects elastic configuration data, historical CPU data, and historical QPS data through the service management platform 200, and generates the service list according to the elastic configuration data, the historical CPU data, and the historical QPS data;

[0068] Integrate, analyze, and process elastic configuration data, historical CPU data, and historical QPS data to generate a service list, which serves as the basis for subsequent adjustment operations.

[0069] Step 203: the container group distribution adjustment device 100 receives the service list sent by the service recommendation adjustment device 300;

[0070] After receiving the service list, you can then plan and execute tasks such as resource adjustments based on the services in the list.

[0071] Step 220: The container group distribution adjustment device 100 creates an adjustment task corresponding to each of the services on the service management platform 220. The adjustment task is configured to sequentially adjust the container group distribution of at least one of the services according to the adjustment requirement information and the adjustment sequence information.

[0072] For each service in the service list, create a dedicated adjustment task and set rules for the task. That is, adjust the number of container groups involved in the service according to the pre-defined adjustment requirements and adjustment sequence information.

[0073] Step 230: The container group distribution adjustment device 100 disables the elastic configuration option of the first service in the service list during the execution of the adjustment task;

[0074] During the actual execution phase of the adjustment task, the elastic configuration option of the first service in the service list is disabled to prevent the elastic configuration from automatically triggering expansion or contraction during the execution of the current adjustment task.

[0075] Step 204: The container group distribution adjustment device 100 detects the elasticity index data of each service;

[0076] The container group distribution adjustment device 100 obtains elasticity index data of each service from the monitoring service 500, providing data basis for subsequent determination of whether the elasticity index data reaches a threshold and whether to terminate the adjustment task.

[0077] Step 205: The container group distribution adjustment device 100 ends the adjustment task corresponding to the third service in the case where the elasticity index data of the third service in the service list reaches the preset elasticity threshold.

[0078] In the case where the elasticity index data of the third service in the service list reaches the preset elasticity threshold, the operation of ending the adjustment task corresponding to the third service is performed, so that the container group of the third service is adjusted to a state suitable for the current load.

[0079] Step 240: The container group distribution adjustment device 100 synchronizes the current adjustment result of the third service to the service management platform, and sets the task state of the adjustment task corresponding to the third service to a completed state.

[0080] After ending the adjustment task of the third service, the current adjustment result of the third service is synchronized back to the service management platform, and the state of the adjustment task corresponding to the third service is updated to a completed state, so that the service management platform 220 records and knows that the adjustment task is executed, facilitating subsequent management and viewing of the task execution.

[0081] Figure 3 A flowchart of a container group distribution adjustment method provided by an embodiment of the present application.

[0082] As shown in Figure 3 The container group distribution adjustment method can include steps 210-230, and the method is applied to a container group distribution adjustment device, as follows:

[0083] Step 210: Obtain a service list and adjustment requirement information; the service list includes at least one service and adjustment order information corresponding to each service;

[0084] Adjustment requirement information: specific requirements or conditions for adjusting the service, including resource allocation, container group quantity, load balancing, and other aspects of the requirement.

[0085] Specifically, all service lists currently running can be obtained from a recommended service adjustment device. Adjustment order information is marked for each service. A service list request can be sent to the adjustment service recommendation device, and elasticity configuration data, historical CPU data, and historical QPS data are collected through the service management platform. Based on these data, a service list is generated and sent back. The services in the service list are arranged from high to low according to the adjustment order information, and are sequentially services without configured elasticity timing strategy, services with unchanged elasticity strategy configured in a preset time period, and services with changed elasticity strategy configured in a preset time period.

[0086] The adjustment sequence information is arranged based on risk quantification evaluation and priority sorting rules. Services without configured elastic timing strategy have no automatic adjustment risk and are adjusted first. Services with fixed elastic strategy can be controlled by turning off the elastic configuration option and are adjusted second. Services with possible changing elastic strategy need real-time monitoring, have high adjustment risk and the lowest priority. Services with low probability of triggering elastic events are screened out. The adjustment sequence is determined in combination with resource optimization targets to maximize the probability of reducing conflicts and improving resource optimization efficiency.

[0087] Adjustment requirement information is obtained from business requirements or documents provided by operation and maintenance teams, such as the number of container groups that need to be adjusted and resource allocation targets. Adjustment requirement information can also be generated by analyzing historical load data, such as CPU usage and QPS, through automated tools.

[0088] By obtaining the service list and adjustment requirement information, it can be determined which services need to be adjusted, as well as the specific content and order of adjustment. Once the services that need to be adjusted and the adjustment sequence are determined, the adjustment process can be based on reliable data and confusion can be avoided.

[0089] In one possible embodiment, step 210 can specifically include the following steps:

[0090] A service list request message is sent to the adjustment service recommendation device to collect elastic configuration data, historical CPU data and historical QPS data through the service management platform, and generate the service list based on the elastic configuration data, the historical CPU data and the historical QPS data.

[0091] The service list sent by the adjustment service recommendation device is received.

[0092] Adjustment service recommendation device: a device or module for analyzing and recommending service adjustment, which generates a service list that needs to be adjusted by collecting and analyzing data such as elastic configuration data, historical CPU data, historical QPS data, etc.

[0093] Service list request message: used to request the adjustment service recommendation device to generate a service list. The service list request message is used to trigger the adjustment service recommendation device to start data collection and analysis.

[0094] Elastic configuration data: current elastic configuration information of a service, including whether to enable elastic expansion, resource threshold, expansion strategy, etc.

[0095] Historical CPU data: CPU usage data of a service in the past period of time, used to analyze the resource usage of the service.

[0096] Historical QPS data: the query rate per second of a service in the past period of time, used to analyze the request load of the service.

[0097] Service management platform: a tool for managing and operating services, providing functions such as service creation, adjustment, monitoring, etc.

[0098] Send a request message to the adjustment service recommendation device to trigger it to start collecting and analyzing data. The adjustment service recommendation device will obtain the elastic configuration data, historical CPU data and historical QPS data from the service management platform. By sending a request message, the data collection and analysis process is started, providing data support for generating a service list.

[0099] The adjustment service recommendation device obtains the elastic configuration data, historical CPU data and historical QPS data from the service management platform. The above data reflects the current configuration and past performance of the service. By collecting elastic configuration data, historical CPU data and historical QPS data, the adjustment service recommendation device can comprehensively understand the resource usage and load performance of the service, providing a basis for generating a service list.

[0100] The adjustment service recommendation device analyzes the collected data, combines elastic configuration, CPU usage and QPS, etc. to determine which services need to be adjusted and generates a service list. The service list may include services that need to be adjusted and the adjustment priority. Through data analysis, the services that need to be adjusted can be intelligently identified, and the adjustment order for the services that need to be adjusted can be assigned to ensure the efficiency and rationality of the adjustment process.

[0101] Receive the service list generated by the adjustment service recommendation device and use it as the input for subsequent adjustment tasks. By receiving the service list, the services that need to be adjusted and the adjustment order are clear, providing clear guidance for subsequent adjustment tasks.

[0102] By collecting and analyzing elastic configuration data, historical CPU data and historical QPS data, adjustment decisions can be made based on actual data, avoiding errors caused by subjective judgments. The adjustment service recommendation device automatically generates a service list, reducing manual intervention and improving efficiency. The service list contains adjustment order information, ensuring that critical services are adjusted first and optimizing resource allocation.

[0103] In one possible embodiment, the services in the service list arranged in descending order of the adjustment order information are as follows:

[0104] Services without elastic timing policies, services with unchanged elastic policies configured in the preset time period, and services with changed elastic policies configured in the preset time period;

[0105] The elastic timing strategy is an elastic strategy triggered based on a fixed time rule.

[0106] If the elastic strategy changes within a preset time period, the possibility of conflict between the elastic strategy and the adjustment task increases.

[0107] Elastic timing strategy: refers to a strategy of automatically adjusting service resources according to a preset time plan, such as peak hours every day.

[0108] Elastic strategy unchanged service: refers to a service whose elastic strategy, such as the upper and lower limits of the number of container group replicas or expansion rules, remains unchanged within a preset time period.

[0109] Elastic strategy changing service: refers to a service whose elastic strategy dynamically adjusts according to load or other conditions within a preset time period.

[0110] Future preset time period: refers to a future time range, such as 9:00-18:00.

[0111] According to the adjustment order information of the service, the services are arranged in order of priority from high to low. Services with high priority will be adjusted first. Ensure that critical services or services that need to be processed first can be adjusted in time, and optimize resource allocation.

[0112] Services without elastic timing strategy configuration need to be adjusted first to ensure the rationality of resource allocation. Services with elastic strategy unchanged within a preset time period have the second priority for adjustment. Services with elastic strategy changing within a preset time period have the lowest priority for adjustment. Through the priority rules, services can be adjusted more targetedly to ensure the rational allocation of resources and stability.

[0113] Specifically, the elastic strategy configuration information of each service can be obtained from the service management platform. The services are classified according to the type of elastic strategy. By obtaining the elastic strategy configuration file in the service management platform, monitoring the recorded elastic strategy change history, generating the service list and sorting the services according to the priority rules, the adjustment order information is generated.

[0114] For example, services without elastic timing strategy configuration are preferentially recommended:

[0115] Service A: no elastic timing strategy configuration.

[0116] Among services with elastic timing strategy configuration, services whose current elastic timing strategy does not change within an hour are preferentially recommended:

[0117] Service B: An elastic timing policy is configured and will not change within the next hour.

[0118] For services with fast-changing elasticity policies, select the largest number of replicas as the current number of replicas:

[0119] Service C: An elastic timing policy is configured, and the elastic timing policy changes rapidly within the next hour. The maximum number of replicas is 10.

[0120] Adjusting the service recommendation mechanism generates the following list of services:

[0121] Service A adjusts the order information to level 1 and does not configure an elastic timing policy.

[0122] Service B adjusts the order information to level 2 and configures an elastic timing policy that does not change within the next hour.

[0123] Service C adjusts the order information to level 3, configures an elastic timing policy, and sets a maximum number of replicas to 10.

[0124] Priority rules allow you to prioritize services without elastic scheduling policies, ensuring optimal resource allocation for these services. Adjusting services based on priority allows for more efficient resource allocation, avoiding waste or shortages. Prioritizing critical services ensures stable resource allocation, improving overall stability. Dynamically adjusting services with elastic policy changes allows for better adaptation to load fluctuations and increased flexibility. Automated adjustment sequencing and task execution reduces manual operations for operations and maintenance personnel, reducing the risk of human error.

[0125] Step 220: Create an adjustment task corresponding to each of the services on the service management platform, wherein the adjustment task is configured to sequentially adjust the container group distribution of at least one of the services according to the adjustment requirement information and the adjustment sequence information;

[0126] Container group: In Kubernetes, a container group is the smallest deployable unit, typically containing one or more containers. A container group is the basic operating unit of a service.

[0127] Based on the adjustment requirements and adjustment sequence, corresponding adjustment tasks are created for each service on the service management platform. Adjustment tasks are executed sequentially to ensure that the container group distribution of the service is adjusted as required.

[0128] The adjustment task adjusts the service container group distribution in stages according to the target configuration information and constraint conditions in the adjustment requirement information, combined with the priority order of the adjustment sequence information. The target configuration information includes, for example, the target number of container groups, the cluster distribution ratio, and the resource utilization balance target. The constraint conditions include, for example, the business continuity requirement and the resource threshold. The priority order includes, for example, the order from low risk to high risk according to the stability of the elasticity strategy.

[0129] First, the low-risk services with no elasticity strategy or stable strategy are processed, and the target migration or the number of replicas is directly adjusted. Then, the high-risk services with a possible change in strategy are processed, and the elasticity configuration is closed, the trigger condition is monitored, or the trough period is selected to ensure controllable adjustment. The specific operations include cross-cluster migration of container groups, modification of the number of replicas, and reallocation of resource quotas. After the adjustment is completed, the elasticity strategy is restored and the effectiveness is verified, achieving the balance between resource optimization and service stability.

[0130] The task content includes the service name, service identification information, adjustment sequence information, adjustment requirement information, and task identification information. The adjustment task can be created using the API or interface of the service management platform. The execution order of the task is managed using the task scheduling.

[0131] By creating an adjustment task, the services can be adjusted in an orderly manner, avoiding resource conflicts or service interruptions. The container group distribution of each service is optimized according to the requirements, improving the stability and performance.

[0132] In step 230, during the execution of the adjustment task, the elasticity configuration option of the first service in the service list is closed, and the first service is configured with a first elasticity strategy in a preset time period. The elasticity configuration option is a switch that controls the execution of the first elasticity strategy of the service. When the elasticity configuration option is closed, the first service stops executing the first elasticity strategy in the preset time period. The first elasticity strategy is an automatic container group management rule configured by the service management platform for the first service.

[0133] First elasticity strategy: refers to a strategy for automatically adjusting the container group under certain conditions, such as load increase or decrease, to achieve automatic expansion or reduction of services.

[0134] The first service is a service configured with a first elasticity policy in a preset time period. The elasticity configuration information of all services can be obtained from the service management platform, including policy type, trigger condition and execution time window. The first services with valid first elasticity policies in the preset time period are screened out. For example, if the preset time period is 10:00-11:00, by checking whether the trigger time of the timing policy falls within the preset time period, whether the current value of the index type policy is close to the index threshold in the index type policy, it is determined whether it is possible to trigger in the next hour. The elasticity switch state of the service is queried through the API, and the service with the first elasticity policy disabled is excluded.

[0135] In the service management platform, the elasticity configuration option of the first service is closed through API or interface operation. First, the elasticity configuration option of the service management platform is a switch to control the execution of the first elasticity policy. By calling the configuration modification interface provided by the platform through API, the closing parameter is transmitted, and after the interface responds successfully, all first elasticity policies of the service are suspended, ensuring that the policies are not executed in the preset time period. Therefore, it is ensured that the number of container groups of the first service will not be automatically adjusted due to the first elasticity policy in the preset time period.

[0136] The elasticity configuration option can be closed using the configuration management tool of Kubernetes. An interface or interface is provided in the service management platform to support the enablement and disablement of the elasticity configuration.

[0137] During the adjustment process, the elasticity configuration option of the first service is closed to ensure that the service will not be automatically adjusted due to the first elasticity policy in the preset time period. In this way, resource fluctuations can be avoided during manual adjustment. After closing the elasticity configuration option, manual adjustment can be more stable, ensuring controllability and stability during the adjustment process.

[0138] Exemplarily, the service list includes the following services:

[0139] Service A: no elasticity timing policy is configured.

[0140] Service B: elasticity timing policy is configured, and elasticity timing policy does not change in the next hour.

[0141] Service C: elasticity timing policy is configured, and elasticity timing policy changes rapidly in the next hour, and the maximum number of container groups is 10.

[0142] Since service B and service C are services configured with a first elasticity policy in a preset time period, the elasticity configuration of service B and service C is closed before the container group distribution adjustment device executes the adjustment task.

[0143] To ensure the stability of the container group distribution adjustment process, the container group distribution adjustment device will close the elastic configuration of service B and service C before the adjustment task is executed. After obtaining the service list and adjustment demand information, the device first identifies service B and service C configured with the first elastic strategy in the preset time period, and then closes the elastic configuration of service B and service C when creating each adjustment task corresponding to the service. This can ensure that service B and service C will not automatically adjust the container group number due to the first elastic strategy during the entire process of executing the adjustment task and sequentially adjusting the container group distribution, thereby avoiding conflicts with manual adjustment tasks, ensuring smooth adjustment according to the plan, and achieving controllable optimization of service resources.

[0144] In an embodiment of the present application, the service list and adjustment demand information are obtained to export the current running service list from the service management platform, and adjustment order information is marked for each service. The adjustment demand information is obtained from business demand or monitoring. The services are adjusted in sequence according to the adjustment order information, which can reasonably allocate resources and avoid resource waste or deficiency.

[0145] The first service in the service list is identified, and the elastic configuration option of the first service is closed in the service management platform to ensure that the container group number of the first service will not be automatically adjusted due to the first elastic strategy within the preset time period. The adjustment tasks of each service are executed in sequence according to the adjustment order information, and the container group distribution of the service is adjusted according to the adjustment demand information, such as expansion, contraction, and rescheduling. Closing the elastic configuration option of the first service avoids resource fluctuations caused by the first elastic strategy during the adjustment process, improving stability. The adjustment task is created and scheduled through the service management platform, reducing manual intervention and improving efficiency.

[0146] In a possible embodiment, after step 210, the following steps can also be included:

[0147] Based on the historical elastic strategy configuration of each service in the service list and the real-time monitoring data representing the current running state of the service, an index value of the change trend of the elastic strategy of each service within the preset time period is predicted;

[0148] For a second service for which the predicted index value of the change trend of the elastic strategy exceeds a preset index value, the maximum container group replica number of the second service is determined, and the second service is configured with a second elastic strategy within the preset time period;

[0149] The elastic replica number of the second service within the preset time period is updated to the maximum container group replica number.

[0150] Second service: a service in the service list that is configured with an elastic strategy and has a relatively fast change speed of the elastic strategy, which is a service that needs special attention and adjustment.

[0151] Real-time monitoring data: Service running status data collected in real-time by monitoring tools, including CPU usage, memory usage, request latency, throughput, concurrent connection number, etc., as direct basis for elasticity policy adjustment, reflecting the current load of the service.

[0152] Pre-set time period: A pre-set future time window for predicting the trend of service elasticity policy changes, helping the system plan resource allocation in advance and avoid the lag of real-time adjustment.

[0153] Indicator value of elasticity policy change trend: Quantitative parameters measuring service running status or elasticity policy, such as CPU utilization percentage, target replica number, request response time, etc.

[0154] Pre-set indicator value: Pre-set threshold, such as triggering scaling when CPU utilization exceeds 80%.

[0155] Maximum container group replica number: The maximum number of container group instances allowed by the service under the elasticity policy. Once this number is exceeded, the service will no longer be scaled.

[0156] Based on the historical elasticity policy configuration data of each service in the service list, combined with real-time monitoring data, time series analysis and machine learning algorithms are used to predict the trend of service elasticity policy changes in the pre-set time period. For example, by analyzing the historical timing scaling time and the current business traffic growth trend, the possibility and frequency of future policy adjustment are determined.

[0157] Set the pre-set indicator value, compare the predicted indicator value of the elasticity policy change trend with the pre-set indicator value, and identify the second service whose indicator value of the elasticity policy change trend exceeds the pre-set indicator value. The second service often faces sudden traffic, business peak, etc., and needs to be intervened in advance to avoid instability caused by frequent adjustment of the elasticity policy.

[0158] For the second service, consider the resource usage upper limit, business traffic peak demand, cluster resource carrying capacity, etc. of the second service to determine the maximum container group replica number. Then update the elasticity replica number of the second service in the pre-set time period to the maximum container group replica number, fix the container group number by "scaling to the upper limit in advance", and avoid repeated triggering of the elasticity policy adjustment in the pre-set time period.

[0159] According to the maximum container group replica number, the elastic replica number of the second service within the preset time period is directly set to the maximum value. The essence of the elasticity strategy is to dynamically change the replica number based on real-time indicators, and when the strategy change trend exceeds the preset threshold, it means that the indicator fluctuates sharply or the strategy triggering frequency is extremely high, for example, frequent expansion and contraction within a short time. At this time, the replica number is fixed to the maximum value, which is equivalent to cutting off the execution path of the elasticity strategy, that is, no matter how the real-time indicator changes, the replica number remains constant. This avoids the rapid increase and decrease of the number of container groups caused by frequent triggering of the strategy, thereby eliminating the volatility of resource allocation.

[0160] The elasticity strategy information of the second service is obtained from the service management platform or the elasticity strategy configuration. The elasticity strategy is parsed to extract the configuration value of the maximum container group replica number. The maximum container group replica number is usually determined in advance based on factors such as service historical peak load and cluster resource upper limit, and has the ability to cope with extreme business scenarios. When the elastic replica number is directly set to this value, it is equivalent to "pre-expanding to the upper limit" within the preset time period, so that the service resource supply is always maintained in a state capable of carrying the maximum load. Even if the business traffic suddenly increases, the elasticity strategy cannot further trigger expansion because the replica number has reached the upper limit, avoiding service overload caused by strategy response delay; at the same time, the replica number will not automatically shrink due to temporary traffic decline, preventing resource shortage when traffic rises after shrinking, thereby achieving stability in resource allocation.

[0161] In this way, resource fluctuations caused by rapid changes in the elasticity strategy can be avoided. Updating the elastic replica number of the second service within the preset time period to the maximum container group replica number can stabilize the resource allocation of the second service and avoid affecting stability due to rapid changes in the elasticity strategy.

[0162] In the service management platform, the elasticity replica number of the second service is set to the maximum container group replica number through the API. In the future, the automatic adjustment function of the elasticity strategy is disabled or limited to ensure that the container group replica number remains unchanged. The container group replica number can be directly modified using the command line tool or API of Kubernetes. An interface or interface is provided in the service management platform to support batch adjustment of the elasticity replica number of services.

[0163] For example, the service list has the following services:

[0164] Service A: no elasticity timing strategy is configured.

[0165] Service B: elasticity timing strategy is configured, and the elasticity timing strategy does not change within the next hour.

[0166] Service C: elasticity timing strategy is configured, and the elasticity timing strategy changes rapidly within the next hour, with a maximum container group replica number of 10.

[0167] The container group distribution adjustment device detects the elasticity rule changes of each service in the service list. It is found that the elasticity rule of service C changes rapidly within the next hour. For service C, the maximum number of elastic replicas, i.e., 10 replicas, is selected.

[0168] The container group distribution adjustment device updates the maximum number of elastic replicas of service C, i.e., 10 replicas, to the K8s cluster, ensuring that service C has sufficient resources to support during the adjustment process.

[0169] The number of elastic replicas of the second service within a future preset time period is updated to the maximum container group replica number, i.e., the number of service replicas is increased in advance, which is equivalent to early elasticity, ensuring that there are enough resources to cope with high load. Early elasticity refers to increasing the number of service replicas in advance to cope with the upcoming high load before the expected load increases. Early elasticity can avoid performance degradation or service interruption due to insufficient resources during high load, ensuring the stability and performance of the service.

[0170] By fixing the number of elastic replicas of the second service to the maximum container group replica number, resource fluctuations caused by rapid changes in elasticity strategy can be avoided, improving stability. After the maximum container group replica number is determined, resources can be allocated more reasonably, avoiding resource waste or deficiency. Fixing the container group replica number within a preset time period enhances the control ability of service resource allocation, facilitating operation and maintenance. Rapid changes in elasticity strategy may cause frequent expansion or reduction of services, affecting performance. The second service is usually a service with high load or rapid changes, and by fixing its container group replica number, the stability of the second service can be ensured.

[0171] In one possible embodiment, after step 210, the following steps can also be included:

[0172] Detecting elasticity indicator data of each service, the elasticity indicator data including CPU usage data and query per second (QPS) data;

[0173] In the case where the elasticity indicator data of a third service in the service list reaches a preset elasticity threshold, ending the adjustment task corresponding to the third service;

[0174] Synchronizing the current adjustment result of the third service to the service management platform, and setting the task state of the adjustment task corresponding to the third service to a completed state.

[0175] Elasticity indicator data: refers to the indicator data used to measure the service elasticity capability, usually including CPU usage data and query per second (QPS) data, reflecting the resource usage and load performance of the service.

[0176] The elasticity indicator data can also include:

[0177] Memory utilization, response time of services, error rate of services, custom metrics.

[0178] Custom metrics: specific metrics defined according to business needs. For example, some services may need to be measured according to specific business metrics such as order volume, user activity, etc.

[0179] CPU usage data: the proportion of CPU resources used by the service during operation, usually expressed in percentage. High CPU usage may indicate high service load.

[0180] QPS data: the number of requests processed by the service per second, used to measure the request load capacity of the service.

[0181] Pre-set elasticity threshold: the threshold value of the pre-set elasticity metric data. When the elasticity metric data reaches or exceeds this threshold, the corresponding operation will be triggered, such as ending the adjustment task.

[0182] Third service: the service whose elasticity metric data reaches the pre-set elasticity threshold during the adjustment process.

[0183] Task status: the current status of the adjustment task, usually including "in progress", "completed", "failed" and other statuses.

[0184] Real-time monitoring of the elasticity metric data of each service to evaluate the resource usage and load performance of the service. Through continuous monitoring, abnormal conditions or resource bottlenecks of the service can be found in time.

[0185] When the elasticity metric data of the third service reaches the pre-set threshold, it is considered that the third service has an abnormality, so the adjustment task of the third service is ended. Avoiding continuing to adjust when the third service has an abnormality, reducing unnecessary resource consumption and potential risks.

[0186] Synchronize the current adjustment result of the third service to the service management platform, ensuring that the data in the platform is consistent with the actual state. Keep the real-time and accuracy of the data in the service management platform, facilitating subsequent management and monitoring.

[0187] Update the adjustment task status of the third service to "completed", indicating that the adjustment work of the task has been completed. Clearly define the task status to facilitate other users to understand the execution of the task.

[0188] Specifically, the CPU usage and QPS data of the service can be collected in real time using monitoring tools. Obtain the elasticity metric data through the API or logs of the service management platform. Compare the collected CPU usage and QPS data with the pre-set threshold. If any of the indicators reaches or exceeds the threshold, trigger the logic to end the adjustment task.

[0189] The preset elastic threshold corresponding to the CPU usage: for example, 80%, which means that the action is triggered when the CPU usage exceeds 80%.

[0190] The preset elasticity threshold corresponding to QPS: for example, 1000 means that the action is triggered when QPS exceeds 1000.

[0191] Call the service management platform's API to complete the third-party service adjustment task. Synchronize the current container group replica count, resource allocation, and other adjustment results to the service management platform. Use the Kubernetes API or command-line tools to update the container group replica count. Provide an API in the service management platform to support task status updates and synchronization of adjustment results.

[0192] In the service management platform, update the status of the adjustment task corresponding to the third service to "Completed." Record the task completion time and details for subsequent analysis. Use a database or task management system to record task status. Provide an interface or API to support querying and updating task status.

[0193] By continuously monitoring elasticity metrics, service anomalies or resource bottlenecks can be detected in real time, allowing timely action. When a service's elasticity metrics reach a preset threshold, the adjustment task is automatically terminated, avoiding further adjustments when the service is already meeting its targets or experiencing anomalies, thus reducing resource waste. Adjustment results are synchronized to the service management platform to ensure that the data on the platform is consistent with the actual status, facilitating subsequent management and monitoring. By promptly terminating adjustment tasks and synchronizing results, stability issues caused by over-adjustments or inconsistent data can be avoided.

[0194] In a possible embodiment, after the above-mentioned steps of synchronizing the current adjustment result of the third service to the service management platform and setting the task status of the adjustment task corresponding to the third service to a completed state, the following steps may be further included:

[0195] Enabling flexible configuration of the third service;

[0196] elastically expand or shrink the third service according to the elasticity indicator data of the third service;

[0197] The elastic expansion is an automated container group adjustment operation that dynamically increases the number of container groups of a service according to pre-configured elastic rules through the automated policy execution mechanism of the service management platform;

[0198] The elastic scaling is an automated container group adjustment operation that dynamically reduces the number of container groups of a service according to pre-configured elasticity rules through the automated policy execution mechanism of the service management platform.

[0199] Elastic configuration: whether the service has the ability to automatically expand or reduce. After enabling elastic configuration, the service can automatically adjust the number of container group replicas based on load.

[0200] Elastic scaling and elastic scaling are dynamic container group adjustment operations implemented by the service management platform based on automatic policy execution mechanism. The core goal is to accurately match service resource configuration with actual load demand. Both operations rely on pre-configured elastic rules, which are usually defined in the form of thresholds, such as triggering scaling when CPU utilization exceeds 80%, or triggering scaling when it is less than 30%, or setting trigger conditions based on request throughput, response delay, etc.

[0201] After the adjustment task is completed and the results are synchronized, the elastic configuration of the third service is re-enabled, allowing the third service to automatically adjust resources based on load. The automatic expansion and reduction capabilities of the third service are restored, ensuring that the third service can dynamically adapt to changes in load.

[0202] Real-time monitoring of the third service's elastic index data, and automatically triggering scaling or scaling operations according to the pre-set elastic strategy. Through elastic scaling or scaling, the resource allocation of the third service can be dynamically adjusted to ensure the stability and performance of the third service when the load changes.

[0203] In the service management platform, enable the elastic configuration option of the third service through API or interface operation. Configure the elastic strategy, including the trigger conditions for scaling and scaling, and the upper and lower limits of the number of container group replicas. Provide interfaces or interfaces in the service management platform to support the enablement and adjustment of elastic configuration.

[0204] Use monitoring tools to collect CPU usage and QPS data of the third service in real time. According to the pre-set elastic strategy, determine whether to trigger scaling or scaling operation. If scaling is needed, increase the number of container group replicas; if scaling is needed, reduce the number of container group replicas. Provide interfaces in the service management platform to support manual triggering of scaling or scaling operations.

[0205] Scaling conditions: such as triggering scaling when CPU usage exceeds 80% or QPS exceeds 1000.

[0206] Scaling conditions: such as triggering scaling when CPU usage is less than 30% or QPS is less than 500.

[0207] By enabling elastic configuration, the third service regains the ability to automatically adjust resources based on load, improving flexibility and adaptability. Based on elastic indicator data, the number of container group replicas can be dynamically adjusted to ensure that the service can expand resources under high load and reduce resources under low load, thereby optimizing resource utilization. Through elastic expansion and contraction, performance issues caused by insufficient or wasted resources can be avoided, and overall stability can be improved. Automated elastic adjustment reduces manual operations by operations and maintenance personnel, reduces the risk of human error, and improves efficiency. Elastic configuration enables services to quickly adapt to changes in business needs, such as sudden traffic or traffic troughs, ensuring the continuous availability and performance of services.

[0208] In a possible embodiment, the following steps may also be included:

[0209] After completing the adjustment task corresponding to the service, storing the container group distribution result of the service;

[0210] The container group distribution result of the service is sent to the service management platform, so as to update the container group distribution result of the service on the service management platform.

[0211] Container group distribution results: This refers to the distribution of container group instances across nodes after the service adjustment task is completed. The container group distribution results include the number of container groups, information about the nodes where the container groups are located, and resource allocation.

[0212] Service Management Platform: A tool or platform used to manage and operate services, providing functions such as service creation, adjustment, and monitoring.

[0213] Adjustment tasks: These tasks optimize the distribution of service container groups, typically including operations such as scaling up, scaling down, and rescheduling.

[0214] After the adjustment task is completed, the adjusted container group distribution results are saved to a database or file. The adjusted container group distribution results include the number of container groups, information about the nodes they are located on, and resource allocation. Storing the container group distribution results preserves the adjustment history for subsequent query, analysis, and auditing.

[0215] The stored container group distribution results are sent to the service management platform to update the container group distribution information on the platform. This ensures that the platform's data is consistent with the actual status. By synchronizing the container group distribution results, the service management platform can reflect the service's resource allocation status in real time, facilitating monitoring and management by operations personnel.

[0216] Specifically, the container group distribution result can be stored in a database or a file storage container group. The stored data includes: the name and ID of the container group; the name and IP address of the node; resource allocation, such as CPU and memory usage; timestamp and operator information of the adjustment task. The data is stored in the database or file using a script or an automation tool.

[0217] The container group distribution result is sent to the platform through the API or message queue of the service management platform. The container group distribution information in the platform is updated to ensure that the container group distribution information in the platform is consistent with the actual state.

[0218] In the embodiment of the application, service list and adjustment requirement information are obtained; the service list includes at least one service and adjustment sequence information corresponding to each service, which can clearly indicate which services need to be adjusted and the specific content and sequence of the adjustment, ensuring that the adjustment process is clear and orderly. An adjustment task corresponding to each service is created on a service management platform, and the adjustment task is configured to sequentially adjust the container group distribution of at least one service according to the adjustment requirement information and the adjustment sequence information, so that the services can be adjusted in order and the container group distribution of each service can be optimized according to the requirements. During the execution of the adjustment task, the elastic configuration option of the first service in the service list is closed, the elastic configuration option is a switch for controlling the execution of the first elastic policy, the first service is configured with the first elastic policy in a preset time period, and the first elastic policy is an automatic container group management rule configured by the service management platform for the first service. Since the first elastic policy dynamically adjusts the number of container groups of the first service, if the first elastic policy is triggered during the execution of the adjustment task, the container group distribution of the first service may be automatically adjusted. When the elastic configuration option is closed, the service will stop executing the first elastic policy in the preset time period, ensuring that the service will not automatically adjust the container group distribution due to the first elastic policy in the preset time period, and ensuring the controllability and stability of the adjustment process.

[0219] Based on the above Figure 3 The embodiment of the application also provides a container group distribution adjustment device, as shown in Figure 4 The container group distribution adjustment device 400 can include:

[0220] The obtaining module 410 is configured to obtain a service list and adjustment requirement information; the service list includes at least one service and adjustment sequence information corresponding to each service.

[0221] The creating module 420 is configured to create an adjustment task corresponding to each service on a service management platform; the adjustment task is configured to sequentially adjust the container group distribution of at least one service according to the adjustment requirement information and the adjustment sequence information.

[0222] The closing module 430 is configured to close an elasticity configuration option of a first service in the service list during execution of the adjustment task, the first service being configured with a first elasticity policy in a preset time period; the elasticity configuration option is a switch for controlling execution of the first elasticity policy of the service, when the elasticity configuration option is closed, the first service stops executing the first elasticity policy in the preset time period; and the first elasticity policy is an automatic container group management rule configured by the service management platform for the first service.

[0223] In a possible implementation, the apparatus 400 further includes:

[0224] The prediction module is configured to predict an index value of a change trend of an elasticity policy of each service in the preset time period based on historical elasticity policy configurations of each service in the service list and real-time monitoring data representing a current running state of the service.

[0225] The determination module is configured to determine a maximum container group replica number of a second service for which the predicted index value of the change trend of the elasticity policy exceeds a preset index value, the second service being configured with a second elasticity policy in the preset time period.

[0226] The updating module is configured to update an elasticity replica number of the second service in the preset time period to the maximum container group replica number.

[0227] In a possible implementation, the apparatus 400 further includes:

[0228] The detection module is configured to detect elasticity index data of each service, the elasticity index data including CPU usage rate data and query per second (QPS) data.

[0229] The ending module is configured to end an adjustment task corresponding to a third service in the service list when it is detected that the elasticity index data of the third service reaches a preset elasticity threshold.

[0230] The setting module is configured to synchronize a current adjustment result of the third service to the service management platform, and set a task state of the adjustment task corresponding to the third service to a completed state.

[0231] In a possible implementation, the apparatus 400 further includes:

[0232] The starting module is configured to start elasticity configuration of the third service.

[0233] The elasticity adjustment module is configured to perform elasticity scaling or elasticity scaling in of the third service according to the elasticity index data of the third service.

[0234] The elastic expansion is an automatic container group adjustment operation of dynamically increasing the number of container groups of a service according to a pre-configured elastic rule through an automatic policy execution mechanism of a service management platform.

[0235] The elastic contraction is an automatic container group adjustment operation of dynamically reducing the number of container groups of a service according to a pre-configured elastic rule through an automatic policy execution mechanism of a service management platform.

[0236] In a possible embodiment, the services in the service list arranged according to the adjustment order information from high to low are as follows:

[0237] Services not configured with an elastic timing policy, services configured with an elastic policy that does not change in the preset time period, and services configured with an elastic policy that changes in the preset time period.

[0238] The elastic timing policy is an elastic policy triggered based on a fixed time rule.

[0239] If the elastic policy changes in a preset time period, the possibility of conflict between the elastic policy and the adjustment task increases.

[0240] In a possible embodiment, the obtaining module 410 is specifically configured to:

[0241] Send a service list request message to the adjustment service recommendation device, so that the adjustment service recommendation device collects elastic configuration data, historical CPU data, and historical QPS data through the service management platform, and generates the service list according to the elastic configuration data, the historical CPU data, and the historical QPS data.

[0242] Receive the service list sent by the adjustment service recommendation device.

[0243] In a possible embodiment, the device 400 further includes:

[0244] The storage module is configured to store the container group distribution result of the service after completing the adjustment task corresponding to the service.

[0245] The sending module is configured to send the container group distribution result of the service to the service management platform, so that the service management platform updates the container group distribution result of the service.

[0246] In an embodiment of the present invention, a service list and adjustment requirement information are obtained. The service list includes at least one service and adjustment sequence information corresponding to each service. This clarifies which services require adjustment, as well as the specific content and sequence of the adjustments, ensuring a clear and orderly adjustment process. An adjustment task is created for each service on the service management platform. The adjustment task is configured to sequentially adjust the container group distribution of at least one service based on the adjustment requirement information and adjustment sequence information. This allows for orderly adjustment of services, ensuring that the container group distribution of each service is optimized as required. During the execution of the adjustment task, the elastic configuration option of the first service in the service list is disabled. The elastic configuration option is a switch that controls the execution of a first elastic policy. The first service is configured with a first elastic policy within a preset time period. The first elastic policy is an automated container group management rule configured for the first service by the service management platform. Because the first elastic policy dynamically adjusts the number of container groups in the first service, if the first elastic policy is triggered during the execution of the adjustment task, the container group distribution of the first service may be automatically adjusted. When the elastic configuration option is disabled, the service will stop executing the first elastic policy for the preset time period, ensuring that the container group distribution of the service will not be automatically adjusted due to the first elastic policy during the preset time period, thereby ensuring the controllability and stability of the adjustment process.

[0247] The embodiment of the present invention further provides an electronic device, such as Figure 5 As shown, it includes a processor 701, a communication interface 702, a memory 703 and a communication bus 704, wherein the processor 701, the communication interface 702, and the memory 703 communicate with each other through the communication bus 704.

[0248] Memory 703, for storing computer programs;

[0249] The processor 701 is configured to execute the program stored in the memory 703, and implement the following steps:

[0250] Obtain a service list and adjustment requirement information; the service list includes at least one service and adjustment sequence information corresponding to each service; create an adjustment task corresponding to each service on the service management platform, and the adjustment task is configured to adjust the container group distribution of at least one service in sequence according to the adjustment requirement information and the adjustment sequence information; during the execution of the adjustment task, turn off the elastic configuration option of the first service in the service list, and the first service is configured with a first elastic policy within a preset time period; the elastic configuration option is a switch that controls the execution of the first elastic policy of the service. When the elastic configuration option is turned off, the first service stops executing the first elastic policy within a preset time period; the first elastic policy is an automated container group management rule configured by the service management platform for the first service.

[0251] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For the convenience of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or only one type of bus.

[0252] The communication interface is used for communication between the terminal and other devices.

[0253] The memory can include a Random Access Memory (RAM) and can also include a non-volatile memory, such as at least one disk memory. Optionally, the memory can also be at least one storage device located away from the processor.

[0254] The processor mentioned above can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; can also be a Digital Signal Processing (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component.

[0255] In another embodiment provided by the application, a computer readable storage medium is also provided, and the computer readable storage medium stores instructions, when the instructions are run on a computer, the computer executes the container group distribution adjustment method in any of the above embodiments.

[0256] In another embodiment provided by the application, a computer program product containing instructions is also provided, when the instructions are run on a computer, the computer executes the container group distribution adjustment method in any of the above embodiments.

[0257] In the embodiments described above, all or some of the steps can be implemented by software, hardware or firmware, or any combination thereof. When implemented in software, all or some of the steps can be implemented in the form of one or more computer programs which are stored in a computer readable medium. The computer readable medium can include one or more of a computer readable storage medium and a computer readable signal medium. The computer readable storage medium can include one or more of a magnetic storage medium (e.g., one or more magnetic tapes), an electronic storage medium (e.g., one or more semiconductor memories or tapes), a mechanical storage medium (e.g., one or more recording chips), or the like. The computer readable signal medium can include a computer readable storage medium which is configured to transmit program code embedded in a modulated data signal. The modulated data signal is one example of a propagated signal which is used to transmit computer programs over a transmission medium. Examples of a propagated signal include, but are not limited to, radio or infrared signals, electronic signals which travel through a wire or cable, or computer readable signals stored on a computer readable medium which is accessed through a computer network such as the Internet. The computer readable medium includes, but is not limited to, one or more of the following: a computer readable storage medium, a computer readable signal medium, and a computer readable transmission medium.

[0258] It should be noted that, in the present document, the terms such as first and second are used only to differentiate one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Also, the terms "comprising", "containing", or any other variant thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include those elements only, but can also include other elements not expressly listed, or other elements inherent in such process, method, article, or apparatus. Without more limitations, an element defined by the phrase "comprising a" does not exclude the existence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0259] Each of the embodiments in the present document is described in a related manner, and the same or similar parts between the embodiments can be referred to each other. Each of the embodiments focuses on the difference from other embodiments. In particular, for the system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the part of the description of the method embodiments.

[0260] The above merely provides the preferred embodiments of the application, and not intended to limit the protection scope of the application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the application shall fall within the protection scope of the application.

Claims

1. A method for adjusting the distribution of container groups, characterized in that: Applied to a container group distribution adjustment device, the method includes: Obtaining a service list and adjustment requirement information; the service list includes at least one service and adjustment sequence information corresponding to each service; Creating, on a service management platform, an adjustment task corresponding to each of the services, the adjustment task being configured to sequentially adjust the container group distribution of at least one of the services according to the adjustment requirement information and the adjustment sequence information; During the execution of the adjustment task, the elastic configuration option of the first service in the service list is turned off, and the first service is configured with a first elastic policy within a preset time period; the elastic configuration option is a switch that controls the execution of the first elastic policy of the service. When the elastic configuration option is turned off, the first service stops executing the first elastic policy within the preset time period; the first elastic policy is an automated container group management rule configured by the service management platform for the first service.

2. The method according to claim 1, characterized in that After obtaining the service list and adjusting the demand information, the method further includes: Based on the historical elasticity policy configuration of each service in the service list and the real-time monitoring data representing the current operating status of the service, predict the indicator value of the elasticity policy change trend of each service within the preset time period; For a second service for which an indicator value of a predicted elasticity policy change trend exceeds a preset indicator value, determining a maximum number of container group replicas for the second service, where the second service is configured with a second elasticity policy within the preset time period; The number of elastic replicas of the second service within the preset time period is updated to the maximum number of container group replicas.

3. The method according to claim 1, characterized in that After obtaining the service list and adjusting the demand information, the method further includes: Detecting elasticity indicator data of each of the services, the elasticity indicator data including: CPU usage data and query rate per second (QPS) data; When it is detected that the elasticity indicator data of the third service in the service list reaches a preset elasticity threshold, ending the adjustment task corresponding to the third service; The current adjustment result of the third service is synchronized to the service management platform, and the task status of the adjustment task corresponding to the third service is set to a completed status.

4. The method according to claim 3, characterized in that After synchronizing the current adjustment result of the third service to the service management platform and setting the task status of the adjustment task corresponding to the third service to a completed state, the method further includes: Enabling flexible configuration of the third service; elastically expand or shrink the third service according to the elasticity indicator data of the third service; The elastic expansion is an automated container group adjustment operation that dynamically increases the number of container groups of a service according to pre-configured elastic rules through the automated policy execution mechanism of the service management platform; The elastic scaling is an automated container group adjustment operation that dynamically reduces the number of container groups of a service according to pre-configured elasticity rules through the automated policy execution mechanism of the service management platform.

5. The method according to claim 1, wherein The services in the service list arranged in descending order according to the adjustment order information are: Services that are not configured with an elastic timing policy, services whose configured elastic policy does not change within the preset time period, and services whose configured elastic policy changes within the preset time period; The flexible timing strategy is a flexible strategy triggered based on fixed time rules; If the elastic policy undergoes configuration changes within a preset time period, the possibility of a conflict between the elastic policy and the adjustment task increases.

6. The method according to claim 1, characterized in that The obtaining of the service list includes: Sending a service list request message to the service adjustment recommendation device, so that the service adjustment recommendation device collects elastic configuration data, historical CPU data, and historical QPS data through the service management platform, and generates the service list according to the elastic configuration data, the historical CPU data, and the historical QPS data; Receive the service list sent by the service adjustment recommendation device.

7. The method according to claim 1, characterized in that The method further comprises: After completing the adjustment task corresponding to the service, storing the container group distribution result of the service; The container group distribution result of the service is sent to the service management platform, so as to update the container group distribution result of the service on the service management platform.

8. A device for adjusting the distribution of container groups, characterized in that: The device comprises: An acquisition module is used to acquire a service list and adjustment requirement information; the service list includes at least one service and adjustment sequence information corresponding to each service; a creation module, configured to create an adjustment task corresponding to each of the services on the service management platform, wherein the adjustment task is configured to sequentially adjust the container group distribution of at least one of the services according to the adjustment requirement information and the adjustment sequence information; A shutdown module is used to shut down the elastic configuration option of the first service in the service list during the execution of the adjustment task, where the first service is configured with a first elastic policy within a preset time period; the elastic configuration option is a switch that controls the execution of the first elastic policy of the service, and when the elastic configuration option is turned off, the first service stops executing the first elastic policy within the preset time period; the first elastic policy is an automated container group management rule configured by the service management platform for the first service.

9. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; Memory for storing computer programs; A processor, configured to implement the method steps described in any one of claims 1 to 7 when executing a program stored in a memory.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images