A method and system for in-place scaling of container groups based on a container cloud platform

Abstract

This application relates to the field of container cloud technology, and provides a method and system for in-place scaling of container groups based on a container cloud platform. The method includes: setting an existing resource limit field and a new resource limit field in the container group resource file of the container cloud platform, where the values of the existing resource limit field and the new resource limit field respectively represent the resource amount currently occupied by the container group and the resource amount to be occupied; monitoring the change situation of the container group resource file, and when it is monitored that the value of the existing resource limit field is different from the value of the new resource limit field, performing an in-place scaling operation on the container group, and after the in-place scaling operation is successfully executed, writing the value of the new resource limit field into the existing resource limit field in the container group resource file to synchronize the state of the container group after the in-place scaling operation to the container cloud platform. Thus, it can not only reduce the number of times of container group restart, but also reduce the interference to the container cloud platform itself, and ensure the stability of the platform.

Description

Technical Field

[0001] This application relates to the technical field of container cloud, and particularly to a method, system, computer-readable storage medium, and electronic device for in-place scaling of container groups based on a container cloud platform. Background Art

[0002] Container technology is a technology that divides hardware resources into isolated groups, enabling the isolated groups to balance conflicting hardware resource usage requirements. A lightweight PaaS platform that uniformly orchestrates containers in a cloud-native scenario is called a container cloud platform.

[0003] Container cloud platforms represented by the Kubernetes cluster can provide various functions such as resource scheduling, service orchestration, application deployment, monitoring logs, configuration management, storage network management, and platform security. Deploying a business application in a container cloud platform actually means deploying the business application in a container group (Pod) of the container cloud platform. A container group consists of a single container or multiple tightly coupled containers and is the smallest deployable unit in the container cloud platform, capable of deploying a running instance of a single business application.

[0004] To ensure the stable operation of business applications in a container cloud platform, the container cloud platform also provides the ability to automatically scale resources, which can be specifically divided into horizontal auto-scaling (Horizontal Pod Autoscaler, abbreviated as HPA) and vertical auto-scaling (Vertical Pod Autoscaler, abbreviated as VPA). Currently, due to the limitations of Kubernetes itself, the vertical auto-scaling of container groups can only be achieved through a rescheduling mechanism, and rescheduling requires the eviction and restart processes of the container group. During this period, the running instance cannot respond to requests, resulting in the business being unavailable.

[0005] In some technical solutions, the resource limit value of the container group is directly modified by invoking the OCI (Open Container Initiative) standard protocol to avoid rescheduling of the container group and achieve vertical auto-scaling. However, since directly modifying the container resources of the container group bypasses the security mechanism of Kubernetes, it may cause the inconsistency between the Kubernetes state and the actual state of the container group, thereby leading to the disorder of the cluster scheduling mechanism and unstable operation. Moreover, directly modifying the container resources of the container group may not be successfully executed. Once the modification fails, the container group may remain in a pending scheduling state, causing the business application to be unable to correctly respond to business requests.

[0006] Therefore, a technical solution is needed to reduce the number of restarts of running instances during vertical auto-scaling while ensuring stability and compatibility, so as to meet the high-availability requirements of business applications in the cloud-native scenario. Summary of the Invention

[0007] The purpose of this application is to provide a method, system, computer-readable storage medium, and electronic device for in-place scaling of container groups based on a container cloud platform to solve or alleviate the problems existing in the above-mentioned prior art.

[0008] To achieve the above purpose, this application provides the following technical solutions:

[0009] This application provides a method for in-place scaling of container groups based on a container cloud platform. The resource file of the container group is provided with an existing resource limit field and a newly set resource limit field. The value of the existing resource limit field is used to represent the amount of resources currently claimed by the container group from the container cloud platform, and the value of the newly set resource limit field is used to represent the amount of resources that the container group is prepared to claim from the container cloud platform. The method includes:

[0010] Monitor the change situation of the resource file of the container group;

[0011] In response to the value of the existing resource limit field being different from the value of the newly set resource limit field, perform an in-place scaling operation on the container group;

[0012] In response to the successful execution of the in-place scaling operation, write the value of the newly set resource limit field into the existing resource limit field in the resource file of the container group to synchronize the state of the container group after the in-place scaling operation to the container cloud platform.

[0013] In a possible implementation manner, the step of performing a scaling operation on the container group in response to the value of the existing resource limit field being different from the value of the newly set resource limit field is specifically:

[0014] In response to the value of the existing resource limit field being less than the value of the newly set resource limit field, and the remaining resources of the node where the container group is located satisfy the resources required by the container group, or, the value of the existing resource limit field is greater than the value of the newly set resource limit field, perform an in-place scaling operation on the container group.

[0015] In a possible implementation manner, the step of performing an in-place expansion operation on the container group is specifically:

[0016] Invoke the backend container runtime corresponding to the container group through the container runtime interface, and write the value of the newly set resource limit field to the resource usage limit field in the control group file corresponding to the container group.

[0017] In a possible implementation, the in-place scale-up / scale-down operation is successfully executed, specifically:

[0018] Successfully write the value of the newly set resource limit field to the resource usage limit field in the control group file corresponding to the container group.

[0019] In a possible implementation, the scale-up / scale-down operation on the container group in response to the difference between the value of the existing resource limit field and the value of the newly set resource limit field further includes:

[0020] In response to the value of the existing resource limit field being less than the value of the newly set resource limit field, and the remaining resources of the node where the container group is located not being able to meet the resources required by the container group, the container cloud platform performs rescheduling on the container group to achieve expansion.

[0021] In a possible implementation, a control component is deployed on the container cloud platform.

[0022] The method further includes:

[0023] The control component determines the recommended resource limit value of the container group;

[0024] In response to the relationship between the recommended resource limit value and the value of the current resource usage field of the container group satisfying a preset condition, the control component writes the recommended resource limit value to the newly set resource limit field in the resource file of the container group, so that the value of the existing resource limit field is different from the value of the newly set resource limit field.

[0025] In a possible implementation, a monitoring system is deployed on the container cloud platform. Correspondingly, the control component determines the recommended resource limit value of the container group, specifically:

[0026] The monitoring system continuously collects and stores the resource usage data of each container group in the container cloud platform;

[0027] The control component accesses the monitoring system at a preset time interval to obtain the resource usage data of the container group; wherein, the preset time interval is determined by the control component according to the historical resource usage data of the container group;

[0028] Generate the recommended resource limit value according to the recent resource usage data of the container group.

[0029] An embodiment of the present application provides a system for in-place scaling of a container group based on a container cloud platform. In the resource file of the container group, there are an existing resource limit field and a newly set resource limit field. The value of the existing resource limit field is used to represent the amount of resources currently declared by the container group to occupy from the container cloud platform, and the value of the newly set resource limit field is used to represent the amount of resources that the container group is prepared to declare to occupy from the container cloud platform. The system includes:

[0030] A monitoring unit configured to monitor the change situation of the resource file of the container group;

[0031] A triggering unit configured to perform an in-place scaling operation on the container group in response to the value of the existing resource limit field being different from the value of the newly set resource limit field;

[0032] A synchronization unit configured to, in response to the successful execution of the in-place scaling operation, write the value of the newly set resource limit field into the existing resource limit field in the resource file of the container group, so as to synchronize the state of the container group after the in-place scaling operation to the container cloud platform.

[0033] An embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the method for in-place scaling of a container group based on a container cloud platform as described in any one of the above is implemented.

[0034] An embodiment of the present application further provides an electronic device, including: a memory, a processor, and a program stored in the memory and executable on the processor. When the processor executes the program, the method for in-place scaling of a container group based on a container cloud platform as described in any one of the above is implemented.

[0035] Advantageous effects:

[0036] In the technical solution of this application, an existing resource limit field and a newly set resource limit field are set in the container group resource file of the container cloud platform. The value of the existing resource limit field represents the amount of resources that the container group currently declares to occupy from the container cloud platform, and the value of the newly set resource limit field represents the amount of resources that the container group is prepared to declare to occupy from the container cloud platform. Monitor the change situation of the container group resource file. When it is monitored that the value of the existing resource limit field is different from the value of the newly set resource limit field, perform an in-place scaling operation on the container group. After the in-place scaling operation is successfully executed, write the value of the newly set resource limit field into the existing resource limit field in the container group resource file, so as to synchronize the state of the container group after the in-place scaling operation to the container cloud platform. In this way, the in-place scaling operation of the container group is triggered by the relationship between the existing resource limit field and the newly set resource limit field. Without restarting the container group, the adjustment of its resource occupancy can be realized, reducing the number of restarts of the container group during the vertical scaling process and also reducing the intrusion of the in-place scaling operation on the original management mechanism; after the in-place scaling operation is successfully executed, write the value of the newly set resource limit field into the existing resource limit field, enabling the container cloud platform to know the latest state of the container group it manages, and then being able to incorporate the container group after the in-place scaling operation into the normal scheduling mechanism, ensuring the stable operation of the entire container cloud platform and also ensuring the compatibility of the container group after the in-place scaling operation with the scheduling mechanism of the entire container cloud platform itself. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The specification drawings forming a part of this application are used to provide a further understanding of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an improper limitation to this application. Among them:

[0038] Figure 1 FIG. is a logical schematic diagram of a method for in-place scaling of a container group based on a container cloud platform according to some embodiments of this application;

[0039] Figure 2 FIG. is a flowchart of a method for in-place scaling of a container group based on a container cloud platform according to some embodiments of this application;

[0040] Figure 3 FIG. is a structural schematic diagram of a system for in-place scaling of a container group based on a container cloud platform according to some embodiments of this application;

[0041] Figure 4 FIG. is a structural schematic diagram of an electronic device according to some embodiments of this application;

[0042] Figure 5 FIG. is a hardware structure diagram of an electronic device according to some embodiments of this application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0043] To facilitate the understanding of the technical solution of this application, the related technologies will be described first below.

[0044] As described in the background art, a pod is the smallest deployable unit in a container cloud platform and can deploy a running instance of a single business application. There are multiple running instances corresponding to a business application deployed in the container cloud platform, which jointly respond to requests directed to the business application. The container cloud platform establishes a load balancing mechanism for all running instances corresponding to the same business application and evenly distributes requests to each running instance according to the load condition of each running instance.

[0045] The auto-scaling ability of the container cloud platform can automatically increase the overall resources occupied by the business application when the load of the business application increases, and automatically reduce the overall resources occupied by the business application when the load of the business application decreases, so as to improve the resource utilization rate of the container cloud platform.

[0046] The auto-scaling ability can be divided into horizontal auto-scaling and vertical auto-scaling. Among them, horizontal auto-scaling refers to the scaling of the number of running instances, that is, when the load of the business application is high, several new application instances are automatically added, and a part of the requests are transferred to the new running instances to reduce the load of the original running instances. When the load of the business application is low, several existing running instances are automatically deleted, and the requests directed to the deleted running instances are transferred to the remaining running instances to reduce the total resources occupied by the business application. Vertical auto-scaling refers to the scaling of the resources occupied by the business application, that is, when the load of the business application is high, more resources are automatically allocated to each running instance corresponding to the business application to improve the load capacity of the business application. When the load of the business application is low, the resources allocated to each running instance corresponding to the business application are automatically reduced, thereby reducing the overall resources occupied by the business application.

[0047] Currently, the horizontal auto-scaling solution has been widely applied. The administrator of the business application can customize the horizontal auto-scaling HPA metrics. The HPA controller will continuously calculate the average resource utilization rate of all running instances corresponding to a business application and adjust the number of running instances to make the average resource utilization rate continuously approach the target value.

[0048] However, the vertical automatic scaling solution has not been widely adopted. The main reason is that to adjust the resources allocated to the running instance, it is actually necessary to adjust the resources allocated to the container group where the running instance is located, that is, to modify the resource limit value of the container group where the running instance is located. Due to the limitations of the container cloud platform itself, the existing technology is used to modify the resource limit value of the container group where the running instance is located. Rescheduling is required, that is, it is necessary to create a new container group with the corresponding resource limit value, reschedule the running instance to the newly created container group, and then delete the original container group. In this process, the running instance needs to be restarted.

[0049] The running instance cannot respond to requests during the restart period. Therefore, using vertical automatic scaling to adjust the load capacity of business applications will cause the business application to be unavailable during the rescheduling of the running instance and unable to respond to requests.

[0050] In order to avoid restarting the container group during vertical scaling, some technologies use the method of directly modifying the actual resource values ​​occupied by the container group to perform vertical scaling. However, this method is equivalent to changing the original scheduling mechanism of the container cloud platform. The container cloud platform cannot perceive the state of the container group after the resources change, making it impossible for the container cloud platform to effectively manage it, resulting in reduced rigor and reliability of the scheduling logic, and sometimes even conflicts with the existing scheduling mechanism, which in turn causes a relatively serious intrusion on the original scheduling mechanism. Therefore, a less intrusive, stable, and compatible technical solution is urgently needed to reduce the number of restarts of running instances during vertical automatic scaling. In other words, the existing vertical automatic scaling solution needs to be optimized to meet the high availability requirements of business applications in cloud native scenarios, so that the vertical automatic scaling solution can be widely used.

[0051] After in-depth analysis, the applicant found that the key to reducing the number of restarts of running instances during vertical automatic scaling is to be able to directly write new resource limit values ​​​​to the running container group, while monitoring the in-place scaling execution process. Once the execution is completed, the execution results can be fed back to the container cloud platform, so that the container cloud platform can be aware of the changes in the status of the container group during the in-place scaling process, and manage it according to the original scheduling mechanism.

[0052] To this end, the present application provides a method, a system, a computer-readable storage medium, and an electronic device for in-place scaling of a container group based on a container cloud platform. In this technical solution, the resource file of the container group is provided with an existing resource limit field and a newly set resource limit field. By listening to the changes in the resources of the container group, the relationship between the value of the existing resource limit field and the value of the newly set resource limit field is obtained. According to the different relationship between the two, the in-place scaling operation of the container group is started. At the same time, during the in-place scaling operation, the execution status of the scaling operation is monitored. By writing the value of the newly set resource limit field into the existing resource limit field, the status of the container group after the in-place scaling operation is synchronized to the container cloud platform. This method can not only reduce the number of restarts of the container group during vertical scaling, but also feedback the latest status of the container group to the container cloud platform, enabling the container cloud platform to manage the container group normally, thereby ensuring the stable operation of the container cloud platform scheduling mechanism and its compatibility with the overall platform.

[0053] The present application will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments. Each example is provided by way of explanation of the present application rather than limitation of the present application. In fact, those skilled in the art will clearly understand that modifications and variations can be made to the present application without departing from the scope or spirit of the present application. For example, features shown or described as part of one embodiment can be used in another embodiment to yield yet another embodiment. Therefore, it is desirable that the present application includes such modifications and variations that fall within the scope of the appended claims and their equivalents.

[0054] Exemplary method

[0055] An embodiment of the present application provides a method for in-place scaling of a container group based on a container cloud platform. The resource file of the container group is provided with an existing resource limit field and a newly set resource limit field. The value of the existing resource limit field is used to represent the amount of resources currently declared by the container group to the container cloud platform for occupancy, and the value of the newly set resource limit field is used to represent the amount of resources that the container group is prepared to declare to the container cloud platform for occupancy. The method includes:

[0056] Step S101, monitor the changes in the resource file of the container group.

[0057] In an embodiment of the present application, multiple nodes are deployed in a container cloud platform (such as a Kubernetes cluster). As Figure 1 shown, according to their different functions, the nodes in the cluster can be divided into two types: control nodes and worker nodes. Figure 1 In the application scenario shown, there is a total of 1 control node and 1 worker node. It should be understood that the number of nodes in the cluster can be set as needed, and the embodiments of the present application do not limit this.

[0058] One or more container groups are running in the working node. The container groups are used to run business applications. Based on the foregoing description, all running instances of the business application jointly respond to requests directed to the business application. The container cloud platform sets up a load balancing mechanism for the business application, which can evenly distribute requests to each running instance according to the load condition of each running instance. Therefore, it is necessary to synchronously perform vertical auto-scaling on each running instance corresponding to the business application. For the sake of convenience of description, the following takes the vertical scaling process of the container group corresponding to one running instance as an example for description.

[0059] In the embodiments of the present application, it is necessary to monitor the change situation of the resource file of the container group to determine whether to start the in-situ scaling operation of the container group. It should be noted that the resource file is a collection of configuration information of the resources required by the cloud-native application, and each cloud-native application corresponds to at least one resource file. Resources are the abstractions of all contents in the container cloud platform, and resource objects (such as container groups) are instances of resources and are persistent entities. The container groups in the container cloud platform can all be defined or described by files in yaml or json format (i.e., the resource files of the container groups). Specifically, the resource file corresponding to the running instance is located on the control node, and the container cloud platform allows access to the unified interface of the container cloud platform (such as the API-Server component of Kubernetes) through the HTTP protocol to obtain the content and change situation of the resource file.

[0060] As Figure 1 shown, the change situation of the resource file is specifically obtained by the node proxy components (such as the Kubelet component of Kubernetes) on each working node by accessing the API-Server component of the control node to monitor the resource file status of the container group.

[0061] In traditional technical solutions, vertical scaling of a container group is achieved through a rescheduling mechanism, and the rescheduling mechanism is triggered by changes in the resource allocation information of the container group itself. That is to say, once the resource allocation information in the resource file of the container group is modified, the rescheduling mechanism of the container cloud platform will be triggered. The scheduler will create a new container group that meets the specifications according to the modified resource allocation information, and at the same time evict the original container group, resulting in the restart of the container group. In order to reduce the number of restarts during the vertical scaling of the container group, meet the high-availability requirements of business applications in the cloud-native scenario, and expand the application scope of the vertical auto-scaling technology, in the embodiments of the present application, an existing resource limit field and a newly set resource limit field are set in the resource file of the container group, which are used to represent the amount of resources currently declared by the container group to occupy from the container cloud platform and the amount of resources to be declared to occupy from the container cloud platform respectively. When the Kubelet component monitors the changes in the resource file of the container group, it can obtain the field values of the existing resource limit field and the newly set resource limit field, and then determine whether to perform a vertical scaling operation on the container group according to the relationship between the field values of the existing resource limit field and the newly set resource limit field.

[0062] Step S102, in response to the value of the existing resource limit field being different from the value of the newly set resource limit field, perform an in-place scaling operation on the container group.

[0063] Specifically, the Kubelet component monitors the resource file of the container group corresponding to the running instance through the API-Server component. When it is detected that the value of the existing resource limit field is different from the value of the newly set resource limit field, it starts to perform vertical scaling on the container group where the running instance is located.

[0064] In the embodiments of the present application, when it is detected that the value of the existing resource limit field is different from the value of the newly set resource limit field, an in-place scaling operation is performed on the container group. That is to say, it is determined whether to perform a vertical scaling operation according to the relationship between the values of the existing resource limit field and the newly set resource limit field. Since the resource allocation information of the container group is not directly modified, the rescheduling is not triggered, and the container group will not restart, avoiding the impact on the business system.

[0065] Furthermore, in order to accurately trigger the vertical scaling operation, in some embodiments, a control component is deployed on the container cloud platform, and the method further includes: the control component determines the recommended resource limit value of the container group; in response to the relationship between the recommended resource limit value and the value of the current resource usage field of the container group meeting a preset condition, the control component writes the recommended resource limit value into the newly set resource limit field in the resource file of the container group, so that the value of the existing resource limit field is in a different state from the value of the newly set resource limit field.

[0066] Specifically, after generating the recommended resource limit value of the container group, the control component determines whether the relationship between the recommended resource limit value and the value of the current resource usage field of the container group meets a preset condition. If so, the control component modifies the value of the newly established resource limit field in the resource file corresponding to the running instance through the API-Server component, and modifies it to the calculated recommended resource limit value.

[0067] In the embodiments of the present application, the control component can be a custom controller developed independently or can be extended based on an existing controller (such as a VPA controller). The present application does not make any limitations in this regard.

[0068] It should be understood that the control component can determine the recommended resource limit value of the container group according to the resource configuration rules. For example, according to the usage of the business application, set the corresponding recommended resource limit values in different scenarios. When the business running state meets the trigger condition of a certain scenario, use the recommended resource limit value corresponding to this scenario as the recommended resource limit value of the container group; or for another example, a regression model can be established based on the historical resource usage to determine the recommended resource limit value. The present application does not make any limitations in this regard.

[0069] When the relationship between the recommended resource limit value and the value of the current resource usage field of the container group meets the preset condition, the control component writes the recommended resource limit value into the newly established resource limit field in the resource file of the container group. In this way, the value of the existing resource limit field and the value of the newly established resource limit field are in different states, which will trigger the in-place scale-out and scale-in operation on the container group.

[0070] Among them, the value of the current resource usage field of the container group represents the resource value currently allocated by the container cloud platform for the container group to use, that is, the resource amount currently declared by the container group to occupy from the container cloud platform. If the container cloud platform cannot allocate the resource of this value to the container group, then the container group will not be created and started.

[0071] Further, the relationship between the recommended resource limit value and the value of the current resource usage field of the container group meeting the preset condition can be that the difference between the recommended resource limit value and the value of the current resource usage field of the container group exceeds a preset threshold, or the recommended resource limit value and the value of the current resource usage field of the container group satisfy a preset functional relationship. The present application does not make any limitations in this regard.

[0072] In the embodiments of the present application, the control component determines the recommended resource limit value. When the recommended resource limit value and the current actual resource usage value of the container group meet the preset condition, by writing the recommended resource limit value into the newly established resource limit field, it triggers the in-place scale-out and scale-in operation on the container group, that is, it is determined that vertical scaling of the container group where the running instance is located is required, making the trigger condition of the in-place scale-out and scale-in operation more reasonable and in line with the actual situation of the business application.

[0073] In addition, to meet special requirements in specific scenarios, the embodiments of the present application allow the application administrator to manually modify the value of the newly set resource limit field in the resource file of the container group to trigger the in-place scaling operation of the container group.

[0074] Furthermore, to improve the accuracy of the recommended resource limit value, in some embodiments, a monitoring system is deployed on the container cloud platform. Correspondingly, the control component determines the recommended resource limit value of the container group, specifically: the monitoring system continuously collects and stores the resource usage data of each container group in the container cloud platform; the control component accesses the monitoring system at a preset time interval to obtain the resource usage data of the container group; wherein, the preset time interval is determined by the control component according to the historical resource usage data of the container group; and a recommended resource limit value is generated based on the recent resource usage data of the container group.

[0075] See Figure 1 , the monitoring system (such as the core monitoring data aggregator Metrics-Server of the Kubernetes cluster or the third-party monitoring system Prometheus) is deployed on the control node. During the operation of the Kubernetes cluster, the monitoring system will continuously collect and store the resource usage of each container group in each worker node and provide an access interface for other components to query.

[0076] The control component can obtain the resource usage data of the container groups where all running instances of the business application are located by accessing the access interface provided by the monitoring system at a preset time interval.

[0077] Among them, the resource usage data of the container group specifically includes the historical resource usage data and the recent resource usage data of the container group. The historical resource usage data refers to the resource usage data generated over a relatively long period in the past, such as 3 months, half a year, or 1 year. The recent resource usage data is the resource usage data generated in a relatively short period recently, such as 15 seconds, 30 seconds, 1 minute, etc. from the current time point.

[0078] In the related art, in order to achieve vertical scaling of a container group, a VPA controller is deployed in a container cloud platform. The VPA controller obtains relevant monitoring data through a monitoring system, that is, the resource usage of all running instances corresponding to a business application within a period of time (such as 8 days), calculates an appropriate resource limit value based on the resource usage within this period, and modifies the resource limit value of the container group where all running instances corresponding to this business application are located in a rescheduling manner, so as to achieve vertical automatic scaling of all running instances corresponding to this business application. However, the resource limit value calculated by this method is based on the resource usage of all running instances corresponding to a business application within a period of time and cannot cope with the sudden increase in the load of the business application.

[0079] In the embodiments of the present application, the time interval for obtaining the resource usage data of the container group, that is, the preset time interval, can be determined by the controller according to the historical resource usage data of the container group, so that the control component can obtain the resource usage data of the container group where the running instance is located from the monitoring system at a reasonable frequency, and generate a recommended resource limit value according to the recent resource usage data of the container group. For example, the recommended resource limit value is calculated according to the resource usage data within the most recent 120 seconds. Such a method can sense the actual running load of the running instance and respond in a timely manner within a short period of time, and at the same time will not cause too much pressure on the control node. Once it is detected that the load of the business application suddenly increases, vertical scaling is immediately performed, thereby improving the sensitivity of vertical scaling.

[0080] In the embodiments of the present application, the monitoring system continuously collects and stores the resource usage data of the container group, determines the time interval for obtaining data according to the historical resource usage data, and then generates a recommended resource limit value according to the recent resource usage data, improving the accuracy of the recommended resource limit value, and further making the trigger of the vertical scaling operation more accurate.

[0081] Based on the foregoing description, it can be seen that the condition for triggering the in-place scaling operation on the container group is that the value of the existing resource limit field is different from the value of the newly set resource limit field. This condition can be further divided into two cases: the value of the existing resource limit field is greater than the value of the newly set resource limit field, or the value of the existing resource limit field is less than the value of the newly set resource limit field. Therefore, in some embodiments, in response to the value of the existing resource limit field being different from the value of the newly set resource limit field, a scaling operation is performed on the container group. Specifically, in response to the value of the existing resource limit field being less than the value of the newly set resource limit field, and the remaining resource amount of the node where the container group is located satisfies the resource amount that the container group needs to occupy, or the value of the existing resource limit field is greater than the value of the newly set resource limit field, an in-place scaling operation is performed on the container group.

[0082] It should be understood that vertical scaling up of the container group where the running instance is located means allocating the remaining resources of the node where the container group is located to the container for use, and vertical scaling down of the container group where the running instance is located means releasing the resources occupied by the container group as the remaining resources of the node where it is located. In the embodiments of the present application, the amount of resources currently declared by the container group to the container cloud platform is represented by the value of the existing resource limit field, and the amount of resources that the container group is prepared to declare to the container cloud platform is represented by the value of the newly set resource limit field. When the value of the existing resource limit field is less than the value of the newly set resource limit field, it indicates that the amount of resources that the container group is prepared to declare to the container cloud platform is larger than the currently occupied resources, and it is necessary to scale it up. At this time, it can be further determined whether the remaining resources of the node where the container group is located can meet the amount of resources that the container group needs to occupy. If so, perform an in-place scaling up operation on it; when the value of the existing resource limit field is greater than the value of the newly set resource limit field, it indicates that the amount of resources that the container group is prepared to declare to the container cloud platform is less than the currently occupied resources, and only an in-place scaling down operation needs to be performed on the container group, without considering the limit of the remaining resources of the node where the container group is located. In this way, by handling different scenarios separately, the stability and security of the in-place scaling up and down operations are further improved.

[0083] Considering that the remaining resources of the current node may not be able to meet the scaling up requirements in some cases, in some embodiments, in response to the values of the existing resource limit field and the newly set resource limit field being different, when performing a scaling up and down operation on the container group, it further includes: in response to the value of the existing resource limit field being less than the value of the newly set resource limit field, and the remaining resources of the node where the container group is located not being able to meet the amount of resources that the container group needs to occupy, the container cloud platform performs rescheduling on the container group to achieve scaling up.

[0084] In this embodiment, after monitoring that the value of the existing resource limit field is less than the value of the newly set resource limit field and determining that it is necessary to perform in-place scaling up on the container group, in order to ensure the correctness and security of the scaling up and reduce the possibility of the scaling up operation failing, before specifically performing in-place scaling up, it is also necessary to first determine whether the remaining resources of the node where the container group is located can meet this scaling up. If the remaining resources of the node where the container group is located can meet this scaling up, the in-place scaling up can be directly performed on the container group where the running instance is located, without the need for rescheduling and thus without restarting. When the remaining resources of the node where the container group is located cannot meet this scaling up, rescheduling is performed on the container group. Thus, when the remaining resources of the node where the container group is located cannot meet the scaling up requirements of the container group, the success of the container group scaling up operation can still be ensured, guaranteeing the normal operation of the business application.

[0085] Briefly speaking, in order to minimize the number of restarts of application instances as much as possible, when the control component vertically scales up the container group where the running instance is located, it is first necessary to determine whether the remaining resources of the node where it is located can meet the resources to be occupied by the container group to be increased. If the remaining resources of the node where it is located are less than the resources to be occupied by the container group to be increased, then the container group cannot be directly scaled up in place and can only be rescheduled by the scheduler, that is, by using the scheduling mechanism provided by the container cloud platform itself. The scheduler creates a container group with corresponding resource limit values on other nodes and directly reschedules the running instance to the newly created container group. After confirming that the remaining resources of the node where it is located can meet the resources to be occupied by the container group to be increased, the container group is directly scaled up in place.

[0086] In the above process, it is determined that the container group needs to be vertically scaled up by the value of the existing resource limit field being less than the value of the newly set resource limit field. When the remaining resources in the node where the container group is located are insufficient and it cannot be directly scaled up in place, the container cloud platform is used to reschedule it to achieve vertical scaling. That is, the two methods of in-place scaling and rescheduling are combined. When the container group is scaled down and the remaining resources of the node where it is located can meet the scaling requirements of the container group, the container group is directly executed for in-place scaling without restarting; when the remaining resources of the node where it is located cannot meet the scaling requirements of the container group, the control component instructs the scheduler of the container cloud platform to reschedule the container group to complete the vertical scaling of the container group. In this way, both the number of restarts of the running instance can be minimized as much as possible, and the scaling failure caused by insufficient remaining resources of the node can be avoided.

[0087] Performing an in-place scaling operation on the container group depends on the container runtime interface (CRI) to update the actual resource value occupied by the container group. Therefore, in some embodiments, performing an in-place scaling operation on the container group specifically includes: calling the backend container runtime corresponding to the container group through the container runtime interface and writing the value of the newly set resource limit field into the resource usage limit field in the control group file corresponding to the container group.

[0088] Furthermore, the operation of changing the actual resource amount occupied by the container group is completed by the Kubelet component of the node where the container group is located. Specifically, the Kubelet component calls the backend container runtime corresponding to the container group through the CRI interface and writes the value of the newly set resource limit field into the resource usage limit field in the control group file (i.e., the Cgroups file) corresponding to the container group, so as to directly modify the resource limit value of the container group where the running instance is located and achieve the effect of in-place scaling of the container group without restarting.

[0089] It should be understood that for the Linux operating system, a container group is equivalent to a process running in the operating system. Cgroups is a mechanism provided by the Linux kernel that can limit the resources used by a single process or multiple processes, enabling fine-grained control of resources such as CPU and memory. The container group uses the resource limiting ability provided by Cgroups to achieve fine-grained control of resources such as CPU and memory. Therefore, to change the resource limit value actually occupied by the container group, the value of the resource usage limit field in the Cgroups file corresponding to the container group needs to be modified, that is, by directly writing a larger resource usage limit value to increase the amount of resources occupied by the container group.

[0090] In this embodiment, the resource usage limit field in the Cgroups file corresponding to the container group is modified by calling the backend container runtime corresponding to the container group through the CRI interface, so as to specifically change the resource limit value actually occupied by the container group. There is no need to reschedule the container group where the running instance is located, and there is no need to restart the running instance, realizing in-place scaling of the running instance.

[0091] In some embodiments, the in-place scaling operation is successfully executed, specifically: the value of the newly set resource limit field is successfully written into the resource usage limit field in the control group file corresponding to the container group.

[0092] That is to say, only after successfully writing the value of the newly set resource limit field into the resource usage limit field in the Cgroups file corresponding to the container group, it is determined that the in-place scaling operation is successfully executed. At this time, since the resource limit value actually occupied by the container group has changed, and the container cloud platform is unaware of these changes, if the actual resource occupancy status of the container group is not timely feedback to the container cloud platform, it may cause chaos in the original management and scheduling mechanisms.

[0093] Step S103, in response to the successful execution of the in-place scaling operation, write the value of the newly set resource limit field into the existing resource limit field in the resource file of the container group, so as to synchronize the status of the container group after the in-place scaling operation to the container cloud platform.

[0094] It should be particularly noted that for a running business instance, the existing CRI interface cannot obtain the current actual resource limit value it occupies. That is to say, the existing CRI interface cannot query the actual status of the CPU and memory resource configurations currently applied to the container by the container runtime. Therefore, a feedback mechanism is needed to synchronize the status of the container group after the in-place scaling operation to the container cloud platform.

[0095] In the embodiment of the present application, when it is monitored that the in-place scaling operation is successfully executed, it indicates that the actual resource limit value of the container group has been successfully modified. At this time, the Kubelet component synchronizes and sets the value of the existing resource limit value field corresponding to the container group to the value of the newly set resource limit value field through the API-Server component. When the Kubelet component monitors that the value of the newly set resource limit value field is the same as the value of the existing resource limit value field, it indicates that the vertical expansion of the container group has been completed. Thus, through the cooperation of different states of the newly set resource limit field and the existing resource limit field, the status feedback and synchronization of the container group are realized.

[0096] It should be understood that the process of writing the value of the newly set resource limit field into the Cgroups file may fail. Therefore, it further includes: when the writing of the value of the newly set resource limit field into the resource usage limit field of the control group file corresponding to the container group fails, the system will try to write the value of the newly set resource limit field into the resource usage limit field of the control group file corresponding to the container group again until the number of attempts exceeds the preset maximum number. At this time, the control component will perform rescheduling on the container group through the container cloud platform to achieve vertical scaling.

[0097] To further understand the above technical solution, the following examples illustrate the numerical changes of the two fields, namely the existing resource limit field and the newly set resource limit field, at different stages of the vertical automatic expansion of the running instance.

[0098] 1. Before the control component performs vertical scaling on the container group where the running instance is located, the values of the two fields, namely the existing resource limit field and the newly set resource limit field, are as shown in the following table:

[0099] Value of the existing resource limit field 10 Value of the newly set resource limit field 10

[0100] 2. The control component calculates that the recommended resource limit value is 15 based on the resource usage data of the container group in the recent period. After confirming that the remaining resource amount of the node where the container group is located exceeds 5 (the difference between the recommended resource limit value 15 and the value 10 of the existing resource limit field), that is, it can meet the resource amount that the container group is prepared to occupy, it is determined to directly expand the container group in place. That is, the value of the newly set resource limit field in the resource file corresponding to the running instance is modified to 15 through the API-Server component. At this time, the values of the two fields, namely the existing resource limit field and the newly set resource limit field, are as shown in the following table:

[0101] Value of the existing resource limit field 10 Value of the newly set resource limit field 15

[0102] 3. When the Kubelet component monitors through the API-Server component that the value of the newly set resource limit field in the resource file is greater than the value of the existing resource limit field, it can determine that vertical scaling up of the container group is to be performed and starts to change the actual resource amount occupied by the container group.

[0103] The Kubelet component calls the CRI interface to modify the value of the resource usage limit field in the control group file corresponding to the container group where the running instance is located to 15. After the modification is successful, it then modifies the value of the existing resource limit field to 15. When the Kubelet component monitors that the values of the existing resource limit field and the newly set resource limit field corresponding to the container group are both 15, it confirms that the vertical scaling up of the container group has been completed. At this time, the numerical values of the two fields, the existing resource limit field and the newly set resource limit field, are as shown in the following table:

[0104] Value of the existing resource limit field 15 Value of the newly set resource limit field 15

[0105] It should be specifically noted that to solve the problem in the related technology of being unable to cope with the sudden increase in the business application load, the above solution sets the control component to obtain the resource usage data of the container group where the running instance is located from the monitoring system frequently (for example, every 120 seconds), and calculates the recommended resource limit value based on the average value of the resource usage data within the interval between two acquisitions, so as to improve the sensitivity of vertical scaling.

[0106] In addition, there may be situations in some special application scenarios where in-place scaling cannot be performed. For this reason, in some optional methods, the application administrator is also allowed to manually set the newly set resource limit field in the resource file corresponding to the business application to cope with emergencies.

[0107] To better conform to the actual business situation, in some other optional implementation methods, a resource adjustment field is also added to the resource file to indicate whether the container group allows vertical in-place scaling operations without restarting to meet the needs of special business scenarios. Specifically, when the value of the resource adjustment field is set to allow in-place scaling operations, vertical in-place scaling can be performed on the container group when the business application load increases to improve the load capacity; otherwise, when the business application load increases, only rescheduling can be used to improve the load capacity.

[0108] In summary, in the technical solution provided by this application, an existing resource limit field and a newly set resource limit field are set in the container group resource file of the container cloud platform. The value of the existing resource limit field represents the amount of resources currently declared by the container group to the container cloud platform for occupancy, and the value of the newly set resource limit field represents the amount of resources that the container group is prepared to declare to the container cloud platform for occupancy. By monitoring the change situation of the container group resource file, when it is monitored that the value of the existing resource limit field is different from the value of the newly set resource limit field, an in-place scaling operation is performed on the container group, and after the in-place scaling operation is successfully executed, the value of the newly set resource limit field is written into the existing resource limit field in the container group resource file to synchronize the state of the container group after the in-place scaling operation to the container cloud platform. In this way, the in-place scaling operation of the container group is triggered by the relationship between the existing resource limit field and the newly set resource limit field, and the adjustment of its resource occupancy can be realized without restarting the container group, reducing the number of restarts of the container group during the vertical scaling process, and at the same time reducing the intrusion of the in-place scaling operation on the original management mechanism; after the in-place scaling operation is successfully executed, the value of the newly set resource limit field is written into the existing resource limit field, enabling the container cloud platform to always know the latest state of the container group it manages, enabling the container cloud platform to incorporate the container group after in-place scaling into the normal scheduling mechanism, ensuring the stable operation of the entire container cloud platform, and also ensuring the compatibility of the container group after in-place scaling with the scheduling mechanism of the entire container cloud platform itself.

[0109] In this application, two fields, namely an existing resource limit field and a newly set resource limit field, are set in the resource file of the container group corresponding to the business application. The control component triggers the vertical scaling of the container group where the running instance is located by modifying the value of the newly set resource limit field, thereby avoiding rescheduling of the container group and reducing the number of restarts.

[0110] In this application, in special scenarios, the application administrator can manually set the newly set resource limit field in the resource file corresponding to the business application to handle emergencies, making the scaling management of the container group more flexible.

[0111] Exemplary system

[0112] An embodiment of this application provides a system for in-place scaling of a container group based on a container cloud platform. The resource file of the container group is provided with an existing resource limit field and a newly set resource limit field. The value of the existing resource limit field is used to represent the amount of resources currently declared by the container group to the container cloud platform for occupancy, and the value of the newly set resource limit field is used to represent the amount of resources that the container group is prepared to declare to the container cloud platform for occupancy; as Figure 3 shown, the system includes: a monitoring unit 301, a triggering unit 302, and a synchronization unit 303. Among them:

[0113] The monitoring unit 301 is configured to monitor the changes in the resource files of the container group.

[0114] The triggering unit 302 is configured to perform an in-place scaling operation on the container group in response to the value of the existing resource limit field being different from the value of the newly set resource limit field.

[0115] The synchronization unit 303 is configured to, in response to the successful execution of the in-place scaling operation, write the value of the newly set resource limit field to the existing resource limit field in the resource file of the container group, so as to synchronize the state of the container group after the in-place scaling operation to the container cloud platform.

[0116] The system for in-place scaling of a container group based on a container cloud platform provided by the embodiments of the present application can implement the processes and steps of the method for in-place scaling of a container group based on a container cloud platform provided in any of the above embodiments, and can achieve the same technical effects, which will not be elaborated here one by one.

[0117] Exemplary device

[0118] Figure 4 Schematic diagram of the structure of an electronic device provided in some embodiments of the present application; as Figure 4 shown, the electronic device includes:

[0119] One or more processors 401;

[0120] A computer-readable medium, which can be configured to store one or more programs 402 and the resource file of the container group. The resource file of the container group is provided with an existing resource limit field and a newly set resource limit field. The value of the existing resource limit field is used to represent the amount of resources currently declared by the container group to the container cloud platform for occupancy, and the value of the newly set resource limit field is used to represent the amount of resources that the container group intends to declare to the container cloud platform for occupancy. When one or more processors 401 execute one or more programs 402, the following steps are implemented: monitoring the changes in the resource file of the container group; performing an in-place scaling operation on the container group in response to the value of the existing resource limit field being different from the value of the newly set resource limit field; in response to the successful execution of the in-place scaling operation, writing the value of the newly set resource limit field to the existing resource limit field in the resource file of the container group, so as to synchronize the state of the container group after the in-place scaling operation to the container cloud platform.

[0121] Figure 5 Hardware structure of an electronic device provided in some embodiments of the present application; as Figure 5 shown, the hardware structure of the electronic device may include: a processor 501, a communication interface 502, a computer-readable medium 503, and a communication bus 504.

[0122] Among them, the processor 501, the communication interface 502, and the computer-readable storage medium 503 communicate with each other through the communication bus 504.

[0123] The computer-readable medium 503 can be configured to store one or more programs and the resource files of the container group. The resource files of the container group are provided with an existing resource limit field and a newly set resource limit field. Among them, the value of the existing resource limit field is used to represent the amount of resources currently declared by the container group to occupy from the container cloud platform, and the value of the newly set resource limit field is used to represent the amount of resources that the container group is prepared to declare to occupy from the container cloud platform.

[0124] Optionally, the communication interface 502 can be an interface of a communication module, such as an interface of a GSM module.

[0125] Among them, the processor 501 can be specifically configured to: monitor the change situation of the resource files of the container group; in response to the value of the existing resource limit field being different from the value of the newly set resource limit field, perform an in-place scale-out or scale-in operation on the container group; in response to the successful execution of the in-place scale-out or scale-in operation, write the value of the newly set resource limit field into the existing resource limit field in the resource file of the container group, so as to synchronize the state of the container group after the in-place scale-out or scale-in operation to the container cloud platform.

[0126] The processor 501 can be a general-purpose processor, including a central processing unit (CPU for short), a network processor (NP for short), etc., and can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. It can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc.

[0127] The electronic device in the embodiments of the present application exists in various forms, including but not limited to:

[0128] (1) Mobile communication device: The characteristic of this type of device is that it has mobile communication functions and mainly aims to provide voice and data communication. This type of terminal includes: smart phones (such as iPhone), multimedia phones, functional phones, and low-end phones, etc.

[0129] (2) Ultra-mobile personal computer device: This type of device belongs to the category of personal computers, has computing and processing functions, and generally also has the characteristic of mobile Internet access. This type of terminal includes: PDAs, MIDs, and UMPC devices, etc., such as iPad.

[0130] (3) Portable entertainment devices: Such devices can display and play multimedia content. This type of device includes: audio and video players (e.g., iPod), handheld game consoles, e-books, as well as smart toys and portable in-vehicle navigation devices.

[0131] (4) Servers: Devices that provide computing services. The composition of a server includes a processor, hard disk, memory, system bus, etc. Servers are similar to general computer architectures, but due to the need to provide highly reliable services, they have higher requirements in terms of processing power, stability, reliability, security, scalability, manageability, etc.

[0132] (5) Other electronic devices with data interaction functions.

[0133] It should be noted that according to the needs of implementation, each component / step described in the embodiments of the present application can be split into more components / steps, or two or more components / steps or partial operations of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of the present application.

[0134] The methods according to the embodiments of the present application described above can be implemented in hardware, firmware, or be implemented as software or computer code that can be stored in a recording medium (such as a CD ROM, RAM, floppy disk, hard disk, or magneto-optical disk), or be implemented as computer code originally stored in a remote recording medium or a non-transitory machine storage medium and downloaded through a network and will be stored in a local recording medium, so that the methods described herein can be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an ASIC or FPGA). It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code. When the software or computer code is accessed and executed by the computer, the processor, or the hardware, the method for in-place scaling of container groups based on a container cloud platform described herein is implemented. In addition, when a general-purpose computer accesses the code for implementing the method shown herein, the execution of the code converts the general-purpose computer into a dedicated computer for executing the method shown herein.

[0135] Those of ordinary skill in the art can realize that the units and method steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or by a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application of the technical solution and the involved constraints. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the embodiments of the present application.

[0136] It should be noted that the various embodiments in this specification are described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other, and the key point of each embodiment is to illustrate the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and reference can be made to the relevant parts of the method embodiments for the relevant content.

[0137] The device and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art can understand and implement it without creative efforts.

[0138] The above are only the preferred embodiments of the present application and are not used to limit the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the protection scope of the present application.

Claims

1. A method for in-place scaling of container groups based on a container cloud platform, characterized in that The resource file of the container group is provided with an existing resource limit field and a newly set resource limit field. The resource file of the container group is used to define the container group. The value of the existing resource limit field is used to represent the amount of resources currently declared by the container group to the container cloud platform for occupancy. The value of the newly set resource limit field is used to represent the amount of resources that the container group is prepared to declare to the container cloud platform for occupancy. The container cloud platform is deployed with a control component; The control component is used to determine the recommended resource limit value of the container group based on the resource usage data of the container group; In response to the relationship between the recommended resource limit value and the value of the current resource usage field of the container group satisfying a preset condition, the control component writes the recommended resource limit value into the newly set resource limit field in the resource file of the container group, so that the value of the existing resource limit field and the value of the newly set resource limit field are in different states; The method includes: The Kubelet component monitors the change situation of the resource file of the container group; In response to the value of the existing resource limit field being different from the value of the newly set resource limit field, the Kubelet component calls the corresponding backend container runtime of the container group through the container runtime interface, and writes the value of the newly set resource limit field into the resource usage limit field in the corresponding control group file of the container group; In response to successfully writing the value of the newly set resource limit field into the resource usage limit field in the corresponding control group file of the container group, the Kubelet component writes the value of the newly set resource limit field into the existing resource limit field in the resource file of the container group, so as to synchronize the state of the container group after the in-place scale-out and scale-in operation to the container cloud platform; In response to the value of the existing resource limit field being the same as the value of the newly set resource limit field, the Kubelet component ends the in-place scale-out and scale-in of the container group.

2. The method for in-place scaling of a container group based on a container cloud platform according to claim 1, wherein The step of, in response to the value of the existing resource limit field being different from the value of the newly set resource limit field, calling the corresponding backend container runtime of the container group through the container runtime interface and writing the value of the newly set resource limit field into the resource usage limit field in the corresponding control group file of the container group, specifically is: In response to the value of the existing resource limit field being less than the value of the newly set resource limit field, and the remaining resource amount of the node where the container group is located satisfies the resource amount required by the container group, or, the value of the existing resource limit field is greater than the value of the newly set resource limit field, call the corresponding backend container runtime of the container group through the container runtime interface, and write the value of the newly set resource limit field into the resource usage limit field in the corresponding control group file of the container group.

3. The method for in-place scaling of a container group based on a container cloud platform according to claim 2, wherein It further includes: In response to the value of the existing resource limit field being less than the value of the newly set resource limit field, and the remaining resource amount of the node where the container group is located cannot satisfy the resource amount required by the container group, the container cloud platform performs rescheduling on the container group to achieve expansion.

4. The method for in-place scaling of a container group based on a container cloud platform according to claim 1, characterized in that The container cloud platform is deployed with a monitoring system, Correspondingly, the control component determines the recommended resource limit value of the container group based on the resource usage data of the container group, specifically as follows: The monitoring system continuously collects and stores the resource usage data of each container group in the container cloud platform; The control component accesses the monitoring system at a preset time interval to obtain the resource usage data of the container group; wherein, the preset time interval is determined by the control component according to the historical resource usage data of the container group; The recommended resource limit value is generated according to the recent resource usage data of the container group.

5. A system for in-place scaling of container groups based on a container cloud platform, characterized in that, The resource file of the container group is provided with an existing resource limit field and a newly set resource limit field. The resource file of the container group is used to define the container group. The value of the existing resource limit field is used to represent the amount of resources currently declared by the container group to occupy from the container cloud platform. The value of the newly set resource limit field is used to represent the amount of resources that the container group is prepared to declare to occupy from the container cloud platform; The container cloud platform is deployed with a control component; The control component is used to determine the recommended resource limit value of the container group based on the resource usage data of the container group; In response to the relationship between the recommended resource limit value and the value of the current resource usage field of the container group satisfying a preset condition, the control component writes the recommended resource limit value into the newly set resource limit field in the resource file of the container group, so that the value of the existing resource limit field and the value of the newly set resource limit field are in different states; The system includes: A listening unit configured to have the Kubelet component listen for changes in the resource file of the container group; A triggering unit configured to, in response to the value of the existing resource limit field being different from the value of the newly set resource limit field, the Kubelet component calls the corresponding backend container runtime of the container group through the container runtime interface and writes the value of the newly set resource limit field into the resource usage limit field in the corresponding control group file of the container group; A synchronization unit configured to, in response to successfully writing the value of the newly set resource limit field into the resource usage limit field in the corresponding control group file of the container group, the Kubelet component writes the value of the newly set resource limit field into the existing resource limit field in the resource file of the container group to synchronize the state of the container group after the in-place scale-out / scale-in operation to the container cloud platform; An ending unit configured to, in response to the value of the existing resource limit field being the same as the value of the newly set resource limit field, the Kubelet component ends the in-place scale-out / scale-in of the container group.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method for in-place scale-out / scale-in of a container group based on a container cloud platform according to any one of claims 1-4.

7. An electronic device, characterized in that, Including: A memory, a processor, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the method for in-place scale-out / scale-in of a container group based on a container cloud platform according to any one of claims 1-4.

Images