System resource adjusting method and device, electronic equipment and storage medium
By creating a target container group in the target resource system and using the resource controller and system daemon to adjust the resource, the problem of mismatch in the application container resource requirements is solved, and efficient resource utilization and container startup are achieved.
Patent Information
- Application Number
- CN202411983377.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-30
- Publication Date
- 2025-05-02
AI Technical Summary
The existing technology cannot effectively solve the problem of mismatch between the resource requirements of the application container during the startup stage and the operation stage, resulting in relatively static resource allocation strategies and the inability to flexibly adapt to the instantaneous high demand of the application, resulting in excessive allocation and waste of resources, and increasing the operating costs of the cloud environment.
Create a target container group in the target resource system and create a configuration identifier for each target container through the resource controller indicating whether to apply accelerated startup configuration. The system daemon monitors the target containers that have applied the accelerated startup configuration, obtains the resource usage status, and adjusts the system resource for each target container based on this status and configuration parameters in the accelerated startup configuration.
It realizes dynamic adjustment of resource allocation during container runtime, optimizes resource utilization, reduces resource waste, reduces operational costs, and accelerates the container startup process.
Smart Images

Figure CN119917271A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer technology, and in particular to a method and device for adjusting system resources, an electronic device, and a storage medium. Background Art
[0002] In the widespread application of container cloud environments, horizontal automatic scaling technology has become the mainstream solution for coping with fluctuations in resource demand. It can automatically expand the number of Pods according to CPU and memory usage to adapt to load changes.
[0003] However, this mechanism cannot fully solve the significant mismatch between resource requirements during application startup and running phases, especially in resource-intensive applications such as Java applications, where resource requirements increase dramatically during startup but decrease significantly after the application enters a stable running state.
[0004] The resource management methods in the existing technology have limitations in dealing with such dynamic demand changes, resulting in relatively static resource allocation strategies that cannot flexibly adapt to the instantaneous high demand of applications, thereby causing over-allocation of resources, resulting in resource waste and increasing the operating costs of the cloud environment.
[0005] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention
[0006] The embodiments of the present invention provide a method and device for adjusting system resources, an electronic device, and a storage medium, so as to at least solve the technical problem in the related art that resources of an application container cannot be dynamically adjusted, resulting in a mismatch between resource allocation and resource demand.
[0007] According to one aspect of an embodiment of the present invention, a method for adjusting system resources is provided, which includes: creating a target container group in a target resource system, wherein a resource controller and a system daemon are deployed in the target resource system, and the target container group includes N target containers, where N is a positive integer; creating a configuration identifier for each of the target containers by the resource controller, wherein the configuration identifier is used to indicate whether the target container applies an accelerated startup configuration; monitoring the target container to which the accelerated startup configuration has been applied by the daemon to obtain monitoring information, wherein the monitoring information is used to record the resource usage status of the target container; and adjusting the system resources of each of the target containers based on the resource usage status indicated by the monitoring information and the configuration parameters recorded in the accelerated startup configuration.
[0008] Furthermore, the step of creating a target container group in the target resource system includes: obtaining the accelerated startup configuration, wherein the accelerated startup configuration records at least: initial resource limit, peak resource limit and accelerated startup duration; creating a container group template based on the configuration parameters recorded in the accelerated startup configuration, wherein the resource request limit of the container is set based on the initial resource limit, the peak resource limit and the accelerated startup duration in the container group template; creating a container group instance based on the container group template to obtain the target container group; and allocating the target container in the target container group to each node of the target resource system to complete container deployment.
[0009] Furthermore, the target resource system is obtained through the following steps: determining M computing nodes in the container orchestration system, where M is a positive integer; registering the computing nodes as system nodes of the target resource system, and generating the target resource system based on the M system nodes; deploying the resource controller and the system daemon in each of the system nodes, wherein the resource controller is used to adjust the accelerated startup configuration, and the system daemon is used to adjust the resource limit of the target container based on the accelerated startup configuration.
[0010] Furthermore, the step of creating a configuration identifier for each target container through the resource controller includes: receiving an accelerated startup policy through the resource controller, and parsing the accelerated startup policy to obtain a parsing result, wherein the parsing result at least includes an accelerated startup object and an accelerated startup parameter; generating the accelerated startup configuration in the target resource system based on the parsing result; generating the configuration identifier for each target container based on the accelerated startup configuration, wherein the configuration identifier is used to edit whether the container applies the accelerated startup policy; storing the configuration identifier in a metadata database of the target resource system, wherein the metadata database is used to record status information and configuration information of container group instances.
[0011] Furthermore, the step of monitoring the target container to which the accelerated startup configuration has been applied through the daemon process to obtain monitoring information includes: running the daemon process, wherein a target communication interface is reserved in the daemon process, and the target communication interface is used to communicate with the target container during the operation of the target container; obtaining the resource usage status of the target container during the operation through the target communication interface, wherein the resource usage status includes at least: CPU usage status and memory usage status; generating a resource usage status report based on the resource usage status to obtain the monitoring information.
[0012] Furthermore, the step of obtaining the resource usage status of the target container during operation through the target communication interface includes: configuring a list observation mechanism for the target communication interface, wherein the list observation mechanism is used to periodically subscribe to resource usage events to the target container; obtaining the resource usage events of the target container within a target time period based on the list observation mechanism, and analyzing the resource usage events to obtain a resource usage data stream; when the resource usage data stream indicates that the resource usage status has changed, triggering an event processing function through the list observation mechanism, wherein the event processing function is used to record the changed resource usage status; and uploading the resource usage status generated by the event processing function to the monitoring information library of the target resource system.
[0013] Furthermore, based on the resource usage status indicated by the monitoring information and the configuration parameters recorded in the accelerated startup configuration, the step of adjusting the system resources for each of the target containers includes: for each of the target containers, comparing the configuration parameters and the resource usage status to obtain a comparison result, wherein the comparison result is used to indicate the difference between the current resource usage demand and the resource configuration of the target container; when the comparison result indicates that the difference exceeds a preset threshold, sending a modification instruction to the target container through the target communication interface, wherein the modification instruction is used to instruct the target container to modify its own configuration parameters based on the accelerated startup strategy; obtaining the resource usage status of the target container after the configuration parameters are modified, and updating the monitoring information library of the target resource system based on the resource usage status.
[0014] According to another aspect of an embodiment of the present invention, a system resource adjustment device is also provided, which includes: a first creation unit, used to create a target container group in a target resource system, wherein a resource controller and a system daemon are deployed in the target resource system, and the target container group includes N target containers, where N is a positive integer; a second creation unit, used to create a configuration identifier for each of the target containers through the resource controller, wherein the configuration identifier is used to indicate whether the target container applies an accelerated startup configuration; a monitoring unit, used to monitor the target container to which the accelerated startup configuration has been applied through the daemon to obtain monitoring information, wherein the monitoring information is used to record the resource usage status of the target container; an adjustment unit, used to adjust the system resources of each of the target containers based on the resource usage status indicated by the monitoring information and the configuration parameters recorded in the accelerated startup configuration.
[0015] Furthermore, the first creation unit includes: a first acquisition module, used to acquire the accelerated startup configuration, wherein the accelerated startup configuration records at least: initial resource limit, peak resource limit and accelerated startup duration; a first creation module, used to create a container group template based on the configuration parameters recorded in the accelerated startup configuration, wherein the resource request limit of the container is set based on the initial resource limit, the peak resource limit and the accelerated startup duration in the container group template; a second creation module, used to create a container group instance based on the container group template to obtain the target container group; an allocation module, used to allocate the target container in the target container group to each node of the target resource system to complete container deployment.
[0016] Furthermore, the system resource adjustment device also includes: a determination module, used to determine M computing nodes in the container orchestration system, wherein M is a positive integer; a first generation module, used to register the computing node as a system node of the target resource system, and generate the target resource system based on the M system nodes; a deployment module, used to deploy the resource controller and the system daemon in each of the system nodes, wherein the resource controller is used to adjust the accelerated startup configuration, and the system daemon is used to adjust the resource limit of the target container based on the accelerated startup configuration.
[0017] Furthermore, the second creation unit includes: a parsing module, which is used to receive the accelerated startup policy through the resource controller, and parse the accelerated startup policy to obtain a parsing result, wherein the parsing result at least includes an accelerated startup object and an accelerated startup parameter; a second generation module, which is used to generate the accelerated startup configuration in the target resource system based on the parsing result; a third generation module, which is used to generate the configuration identifier for each target container based on the accelerated startup configuration, wherein the configuration identifier is used to edit whether the container applies the accelerated startup policy; a storage module, which is used to store the configuration identifier in the metadata database of the target resource system, wherein the metadata database is used to record the status information and configuration information of the container group instance.
[0018] Furthermore, the monitoring unit includes: a running module, used to run the daemon process, wherein a target communication interface is reserved in the daemon process, and the target communication interface is used to communicate with the target container during the operation of the target container; a second acquisition module, used to obtain the resource usage status of the target container during the operation through the target communication interface, wherein the resource usage status includes at least: CPU usage status and memory usage status; a fourth generation module, used to generate a resource usage status report based on the resource usage status to obtain the monitoring information.
[0019] Furthermore, the second acquisition module includes: a configuration submodule, used to configure a list observation mechanism for the target communication interface, wherein the list observation mechanism is used to periodically subscribe to resource usage events to the target container; an analysis submodule, used to obtain the resource usage events of the target container within a target time period based on the list observation mechanism, and analyze the resource usage events to obtain a resource usage data stream; a trigger submodule, used to trigger an event processing function through the list observation mechanism when the resource usage data stream indicates that the resource usage status has changed, wherein the event processing function is used to record the changed resource usage status; an upload submodule, used to upload the resource usage status generated by the event processing function to the monitoring information library of the target resource system.
[0020] Furthermore, the adjustment unit includes: a comparison module, used to compare the configuration parameters and the resource usage status for each target container to obtain a comparison result, wherein the comparison result is used to indicate the difference between the current resource usage demand and the resource configuration of the target container; a sending module, used to send a modification instruction to the target container through the target communication interface when the comparison result indicates that the difference exceeds a preset threshold, wherein the modification instruction is used to instruct the target container to modify its own configuration parameters based on the accelerated startup strategy; an updating module, used to obtain the resource usage status of the target container after the configuration parameters are modified, and update the monitoring information library of the target resource system based on the resource usage status.
[0021] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is further provided, wherein the computer-readable storage medium includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute any of the above-mentioned system resource adjustment methods.
[0022] According to another aspect of an embodiment of the present invention, there is also provided an electronic device, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any one of the above-mentioned system resource adjustment methods.
[0023] In the present invention, a method for adjusting system resources is proposed. First, a target container group is created in a target resource system, wherein a resource controller and a system daemon are deployed in the target resource system, and the target container group includes N target containers, where N is a positive integer. Then, a configuration identifier is created for each target container through the resource controller, wherein the configuration identifier is used to indicate whether the target container applies an accelerated startup configuration. Then, the target container to which the accelerated startup configuration has been applied is monitored through the daemon to obtain monitoring information, wherein the monitoring information is used to record the resource usage status of the target container. Finally, based on the resource usage status indicated by the monitoring information and the configuration parameters recorded in the accelerated startup configuration, the system resources of each target container are adjusted.
[0024] In the present invention, a method of creating a target container group in a target resource system is adopted, and a configuration identifier is created by a resource controller and a system daemon process is used to monitor the use of container resources, so as to achieve the purpose of dynamically adjusting the resource allocation when the container is running, thereby realizing the technical effects of optimizing resource utilization, accelerating container startup and reducing operating costs. Specifically, whether the container applies the accelerated startup strategy is clarified through the configuration identifier, and the daemon process automatically adjusts the resource limit of the container according to the real-time monitored resource usage status and the preset accelerated startup configuration parameters, so that the container obtains sufficient resources in the startup phase, which accelerates the startup process, and automatically reduces resources after stable operation, thereby avoiding resource waste, thereby solving the technical problem in the related technology that the application container cannot be dynamically adjusted in resources, resulting in a mismatch between resource allocation and resource demand. BRIEF DESCRIPTION OF THE DRAWINGS
[0025] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:
[0026] Figure 1 is a flow chart of an optional method for adjusting system resources according to an embodiment of the present invention;
[0027] Figure 2 is a schematic diagram of an optional device for adjusting system resources according to an embodiment of the present invention;
[0028] Figure 3 The present invention is a hardware structure block diagram of an electronic device (or mobile device) for executing a method for adjusting system resources according to an embodiment of the present invention. DETAILED DESCRIPTION
[0029] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.
[0030] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0031] To facilitate those skilled in the art to understand the present invention, some terms or nouns involved in the embodiments of the present invention are explained below:
[0032] K8s, Kubernetes, container orchestration system, an open source container orchestration platform, is used to automate the deployment, expansion and management of containerized applications. It provides a framework for running distributed systems, allowing users to manage containers and applications through declarative configuration, greatly simplifying the deployment and operation process of containerized applications.
[0033] Container Cloud Environment, Containerized Cloud Computing Environment, is an environment built based on cloud computing technology. Applications and data are encapsulated in containers for easy deployment, management, and dynamic scaling in the cloud. This environment uses the advantages of container technology, such as lightweight, portability, and scalability, to provide more efficient application operation and resource management.
[0034] Pod, container group, the basic deployment unit in Kubernetes, can contain one or more containers. Pods are designed to run instances of a single application, where containers share storage and network resources, providing a unified environment to run and manage containers.
[0035] CRD, Custom Resource Definition, is an extension mechanism in Kubernetes that allows users to create and use custom resources through declarative APIs to extend the functionality of Kubernetes to meet specific application requirements or management processes.
[0036] SUP, SpeedUpPolicy CRD, speedup policy custom resource, a custom resource defined in this invention, is used to describe and manage the accelerated startup policy of the container, including parameters such as resource request, peak resource limit and duration of accelerated startup, aiming to optimize resource allocation during the container startup phase.
[0037] SUP-controller, SpeedUpPolicy CRD Controller, acceleration policy controller, as the Operator of SUPCRD, is responsible for monitoring the changes of SUP resources and updating and adjusting the configuration of Pod according to these changes to implement the acceleration startup strategy and ensure that the container obtains sufficient resources during the startup phase.
[0038] sup-daemon, SpeedUpPolicy Daemon, acceleration policy daemon, a daemon running on each Kubernetes node, is responsible for executing the specific operations of the SUP policy, including interacting with the container runtime interface CRI and dynamically adjusting the resource limits of the container to ensure the effective execution of the policy and real-time adjustment of resources.
[0039] The following embodiments of the present invention can be applied to various systems / applications / devices that require dynamic resource adjustment and accelerated container startup, and can achieve efficient resource utilization and significantly shorten the startup time. The present invention uses SpeedUpPolicy CRD (configuration identifier) to manage container resource policies, and then monitors the container resource usage status in real time through the system daemon (sup-daemon), which can better respond to the resource demand peak of the application during the startup phase, automatically adjust resource allocation, and reduce resource consumption after the application runs stably to avoid resource waste.
[0040] The present invention is described in detail below in conjunction with various embodiments.
[0041] Embodiment 1
[0042] According to an embodiment of the present invention, an embodiment of a method for adjusting system resources is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.
[0043] Embodiments of the present invention Figure 1 The system resource adjustment method shown in the figure is implemented by a resource management system of computer cloud resources, which is combined with container cloud environment technology to optimize resource management scenarios, especially to solve the problem of mismatch between resource requirements of application containers in the startup phase and the running phase. By introducing SpeedUpPolicy CRD (SUP) and corresponding controllers and daemons, the specific steps are to create a target container group, assign an accelerated startup configuration identifier to the container, monitor the container resource usage status in real time and dynamically adjust resource restrictions, so as to achieve efficient resource utilization and accelerate container startup.
[0044] Figure 1 is a flow chart of an optional method for adjusting system resources according to an embodiment of the present invention. Figure 1 As shown, the method comprises the following steps:
[0045] Step S101 : creating a target container group in a target resource system, wherein a resource controller and a system daemon are deployed in the target resource system, and the target container group includes N target containers, where N is a positive integer.
[0046] Specifically, the target resource system refers to a system that supports container orchestration and management, such as Kubernetes (K8s), which is used to provide a framework for running distributed systems, allowing users to automatically deploy, scale, and manage containerized applications, while supporting dynamic adjustment of resources.
[0047] In the target resource system (such as Kubernetes), the target container group is represented as a collection of Pods, where Pod is the basic deployment unit in Kubernetes and can contain one or more containers. When creating a target container group, the system will generate multiple Pod instances based on the container group template, and these Pod instances will be allocated to each node of the target resource system to form a container group that can adjust resources according to the accelerated startup configuration.
[0048] In an optional embodiment, a resource controller refers to a controller capable of managing container resources, such as the SUP-controller in the present invention, which is used to monitor changes in custom resource definitions (CRDs), automatically adjust container resource requests and restrictions according to the acceleration startup configuration in the container group template, and ensure the correct application of acceleration strategies.
[0049] In the target resource system of an embodiment of the present invention, the daemon process refers to a DaemonSet component running on each system node, such as sup-daemon, which is responsible for monitoring the resource usage status of the target container and dynamically adjusting the resource limits of the container through interaction with the container runtime interface (CRI) according to the instructions of the SUP-controller.
[0050] Optionally, step S101 includes: obtaining an accelerated startup configuration, wherein the accelerated startup configuration records at least: an initial resource limit, a peak resource limit, and a duration of the accelerated startup; creating a container group template based on the configuration parameters recorded in the accelerated startup configuration, wherein the resource request limit of the container is set in the container group template based on the initial resource limit, the peak resource limit, and the duration of the accelerated startup; creating a container group instance based on the container group template to obtain a target container group; allocating the target container in the target container group to each node of the target resource system to complete the container deployment.
[0051] It should be noted that the accelerated startup configuration is a set of predetermined policy settings that describe the resource characteristics required by the container during the startup phase, including at least the initial resource limit, peak resource limit, and accelerated startup duration. The above parameters are used to guide SUP-controller and sup-daemon on how to optimize the resource allocation of the container.
[0052] Another thing that needs to be explained is that the initial resource limit refers to the default resource limit of the container when the accelerated startup policy is not applied, which is used to reflect the amount of resources required by the container during the stable operation stage; the peak resource limit refers to the maximum resource limit that the container can obtain under the accelerated startup policy, which is used to meet the high resource requirements during the container startup phase; the accelerated startup duration refers to the length of time that the container can maintain the peak resource limit under the accelerated startup policy. After this period, the container's resource limit will be adjusted back to the initial resource limit to avoid resource waste.
[0053] Furthermore, resource request limits refer to container resource requests and container resource limits set in the container group template, wherein resource requests represent the minimum amount of resources required by a container when it is started, and resource limits represent the maximum amount of resources that a container can use. In the present invention, resource request limits will be dynamically adjusted according to the accelerated startup configuration.
[0054] A container group instance is an actual running container group created based on a container group template, consisting of multiple target containers. These container instances will run on each node of the target resource system, and automatically adjust resource allocation according to the accelerated startup configuration.
[0055] It should be noted that the target resource system consists of multiple nodes (i.e., servers or virtual machines), each of which runs a sup-daemon daemon process. The target containers in the container group instance will be assigned to these nodes. Each node is responsible for running the container instance and executing the sup-daemon's resource adjustment instructions.
[0056] The present invention creates and deploys a target container group in a target resource system, and realizes dynamic adjustment of container resources based on accelerated startup configuration through the collaborative work of a resource controller and a system daemon process, optimizes the startup process and operating efficiency of the container, and solves the problem of mismatch between resource requirements in the container startup phase and the operating phase.
[0057] Optionally, the target resource system is obtained through the following steps: determining M computing nodes in the container orchestration system, where M is a positive integer; registering the computing nodes as system nodes of the target resource system, and generating the target resource system based on the M system nodes; deploying a resource controller and a system daemon in each system node, wherein the resource controller is used to adjust the accelerated startup configuration, and the system daemon is used to adjust the resource limit of the target container based on the accelerated startup configuration.
[0058] It should be noted that the container orchestration system is a system that automatically manages and schedules container applications. It can run, replicate, deploy and expand containerized applications across multiple computing nodes or hosts. It is used to provide functions such as container lifecycle management, service discovery, load balancing, storage orchestration, etc., achieving high availability and elastic scalability of applications.
[0059] A computing node is a physical or virtual host in a container orchestration system, responsible for running container instances and providing computing resources. The computing node runs container runtimes and necessary system services, and is the basic environment for running containerized applications. In the present invention, M computing nodes constitute the infrastructure of the target resource system, which is used to carry and run containerized applications.
[0060] In the container orchestration system, computing nodes need to register as system nodes through a specific process, that is, nodes that can be scheduled by the container orchestration system. The registration process usually involves installing necessary components (such as kubelet, Docker or other container runtimes), configuring networks and storage, and communicating with the control plane of the container orchestration system (such as apiserver) to report node status and receive scheduling instructions.
[0061] Based on the M registered system nodes, the container orchestration system builds a resource system that can automatically orchestrate, manage and schedule container applications, namely the target resource system. The system allows users to define resources such as container groups, services, storage volumes, and automatically allocates these resources among the M system nodes to meet the operating requirements of the application.
[0062] Deploy resource controllers (such as SUP-controller) and system daemons (such as sup-daemon) on each system node. The resource controller is responsible for monitoring and processing changes in custom resource definitions (CRDs), and dynamically adjusting container resource requests and limits based on the accelerated startup configuration; the system daemon is a component running on the node, which interacts with the container runtime interface (CRI), monitors container resource usage in real time, and adjusts container resource limits based on the instructions of the resource controller to ensure the execution of the accelerated startup strategy.
[0063] Through the above steps, the present invention constructs a target resource system specifically for container accelerated startup optimization. The system deploys resource controllers and daemons on multiple computing nodes to achieve dynamic adjustment of resources for target containers in container group instances, ensuring that containers can quickly obtain required resources during the startup phase and automatically release excess resources during the running phase, thereby improving resource utilization efficiency, reducing startup delays, and optimizing the overall performance of container applications.
[0064] It should be noted that in the process of building the target resource system, the registration and configuration of the system nodes is a key step to ensure that the computing nodes can maintain communication with the control plane of the container orchestration system, receive scheduling instructions and report status information. The deployment of resource controllers and daemons is the core of implementing the accelerated startup strategy. The container resource status is monitored through the list observation mechanism, and resources are adjusted through the CRI interface to ensure the real-time and accuracy of the strategy. In addition, the system also uses the custom resource definition (CRD) mechanism to allow users to customize the parameters of the accelerated startup strategy, increasing the flexibility and scalability of the system.
[0065] Step S102: Create a configuration identifier for each target container through a resource controller, wherein the configuration identifier is used to indicate whether the target container applies an accelerated startup configuration.
[0066] It should be noted that the configuration identifier is a label or identifier generated by the resource controller for each target container, which is used to indicate whether the target container should follow the accelerated startup configuration for resource adjustment. In the Kubernetes environment, the configuration identifier can be expressed as an annotation or label of the Pod or container, so that the container runtime environment and other system components can identify and apply the corresponding acceleration strategy.
[0067] Optionally, step S102 includes: receiving an accelerated startup policy through a resource controller, and parsing the accelerated startup policy to obtain a parsing result, wherein the parsing result at least includes an accelerated startup object and an accelerated startup parameter; generating an accelerated startup configuration in a target resource system based on the parsing result; generating a configuration identifier for each target container based on the accelerated startup configuration, wherein the configuration identifier is used to edit whether the container applies the accelerated startup policy; storing the configuration identifier in a metadata database of the target resource system, wherein the metadata database is used to record status information and configuration information of container group instances.
[0068] Specifically, the accelerated startup object refers to the container instance or Pod to which the accelerated startup policy needs to be applied, and is the target directly acted upon by the accelerated startup configuration. In the present invention, any container marked by the SUP-controller as requiring accelerated startup can be regarded as an accelerated startup object.
[0069] Speedup parameters are specific configuration values included in the speedup strategy, including but not limited to: initial resource limits, peak resource limits, and duration of speedup. They define the resource requirements and limit adjustment strategies of the container during the speedup phase.
[0070] The accelerated launch configuration is a complete description of the accelerated launch strategy of the container, which consists of accelerated launch parameters and is used to instruct the resource controller how to adjust the resource requests and limits of the container. The configuration is usually defined in a custom resource definition (CRD), parsed by the SUP-controller and applied to each container instance on the target container group.
[0071] The metadata repository is a database used to store and manage the status and configuration information of container group instances in the target resource system. In Kubernetes, etcd (a highly available distributed key-value storage) can be used as a metadata repository to ensure the persistence and consistency of container status and configuration, so that the system can maintain reliability and efficiency in terms of fault recovery, node communication, and status tracking.
[0072] Furthermore, the status information stored in the metadata database refers to the real-time status information of the containers in the container group instance during operation, including the container's operating status, resource usage, network status, etc.; the configuration information includes static configuration information such as the container's initialization settings, accelerated startup configuration parameters, resource requests and restrictions. The above information is crucial for the resource controller and daemon process to monitor the container status in real time, apply accelerated startup strategies, and perform troubleshooting and resource optimization.
[0073] An optional embodiment, in actual deployment, a resource controller (such as SUP-controller) receives and parses the accelerated startup policy submitted by the user, which clearly specifies the target container group (Pods set) and specific accelerated startup parameters (such as resource requests, resource limits, and duration); based on the parsing results, SUP-controller can generate an accelerated startup configuration and create a configuration identifier for each container instance in the container group, which is achieved by adding labels or annotations to the container metadata. For example, an annotation "speedup / enable:true" can be added to the container to indicate that the container should follow the accelerated startup policy.
[0074] Furthermore, the acceleration startup configuration and the configuration identifier of the container are stored in the metadata database of the target resource system to ensure the persistence and consistency of the container status and configuration information. In the Kubernetes environment, the etcd database will be used to store this information, so that the status and configuration of the container can be shared between nodes while maintaining high availability and consistency of the data.
[0075] Through the above steps, the present invention realizes the dynamic management and application of the container acceleration startup strategy, improves the startup speed and resource utilization efficiency of the container application, and also enhances the manageability and scalability of the system.
[0076] Step S103: Monitor the target container to which the accelerated startup configuration has been applied through a daemon process to obtain monitoring information, wherein the monitoring information is used to record the resource usage status of the target container.
[0077] Specifically, resource usage status refers to the usage of computing resources such as CPU and memory during the operation of the container, including the current amount of resources consumed, resource utilization rate, peak usage, etc., which is crucial for determining whether the container needs to accelerate resource adjustment of the startup strategy.
[0078] Optionally, step S103 includes: running a daemon process, wherein a target communication interface is reserved in the daemon process, and the target communication interface is used to communicate with the target container during the operation of the target container; obtaining the resource usage status of the target container during the operation through the target communication interface, wherein the resource usage status includes at least: CPU usage status and memory usage status; generating a resource usage status report based on the resource usage status to obtain monitoring information.
[0079] In the present invention, the target communication interface refers to the communication interface between the daemon process and the container runtime (such as Docker, Containerd, etc.), especially the container runtime interface (CRI). The daemon process can obtain the real-time status information of the container through this interface, including the resource usage status, and dynamically adjust the resource limit of the container according to the accelerated startup strategy.
[0080] CPU usage status and memory usage status are specific manifestations of resource usage status. CPU usage status reflects the CPU resources consumed by the container, including the number of CPU cores currently in use and CPU usage rate, etc. Memory usage status reflects the memory resources consumed by the container, including the current amount of memory in use and memory usage rate, etc., which is crucial for determining whether the container has reached its peak resource demand and when it should be restored to the initial resource limit.
[0081] The resource usage status report is a report information generated by the daemon based on the resource usage status obtained through real-time monitoring. It is used to record the resource usage of the container during accelerated startup, including the peak and average usage of CPU and memory, and detailed information on any resource adjustments. It provides key data support for subsequent resource optimization, troubleshooting, log auditing and other operations.
[0082] In step S103, a daemon process (such as sup-daemon) runs on each node, and a target communication interface is reserved for communicating with the container runtime. The daemon process continuously monitors the target container to which the accelerated startup configuration has been applied through the CRI interface to obtain the CPU usage status and memory usage status of the container in real time. The monitoring information includes but is not limited to the current CPU consumption, CPU usage rate, memory consumption and memory usage rate.
[0083] The daemon process uses a list-watch mechanism to respond to changes in container resource usage status in a timely manner. When container resource usage reaches a preset peak or duration, the daemon process will generate a resource usage status report, i.e., monitoring information, based on the accelerated startup configuration. The report details the container resource usage and the execution of the accelerated startup strategy, including key information such as the time point of resource adjustment and the resource limit values before and after the adjustment.
[0084] The monitoring information generated by the daemon process is an important basis for resource controllers (such as SUP-controller) to determine whether the target container needs resource adjustment. When sup-daemon detects that the container resource usage exceeds the preset acceleration startup duration or the container resource demand returns to a stable state, it will generate a corresponding resource usage status report, including the current resource usage of the container, whether the conditions for the acceleration end have been met, etc., which will be stored in the metadata database of the target resource system for SUP-controller to read and analyze. Based on the monitoring information, SUP-controller can determine whether the container should be restored from the acceleration startup state to the initial resource state, thereby avoiding resource waste and achieving efficient resource utilization.
[0085] The communication between the daemon process and the container runtime and the generation of status reports are key steps in the present invention to achieve dynamic adjustment of container resources. By real-time monitoring and reporting of the resource usage status of the container, the system can ensure the accurate execution of the accelerated startup strategy, and restore resources in time after the strategy execution is completed, avoiding long-term occupation of resources and maintaining the flexibility and efficiency of the resource pool.
[0086] Optionally, the step of obtaining the resource usage status of the target container during operation through the target communication interface includes: configuring a list observation mechanism for the target communication interface, wherein the list observation mechanism is used to periodically subscribe to resource usage events to the target container; obtaining the resource usage events of the target container within a target time period based on the list observation mechanism, and analyzing the resource usage events to obtain a resource usage data stream; when the resource usage data stream indicates that the resource usage status has changed, triggering an event processing function through the list observation mechanism, wherein the event processing function is used to record the changed resource usage status; and uploading the resource usage status generated by the event processing function to the monitoring information library of the target resource system.
[0087] It should be noted that the list-watch mechanism is a communication strategy between the daemon and the container runtime, which allows the daemon to subscribe to resource usage events from the target container periodically, so as to obtain changes in the container resource usage status in real time. In the Kubernetes environment, the daemon usually uses the List-watch mechanism provided by the Kubernetes API Server to continuously monitor the resource usage of the container through the target communication interface, that is, the container runtime interface (CRI).
[0088] The list observation mechanism configured by the daemon process can regularly obtain the resource usage events of the target container within a certain period of time, including updates on CPU and memory usage. These resource usage events are captured by the daemon process through the CRI interface and form a resource usage data stream.
[0089] The resource usage data stream refers to the sequence data consisting of resource usage events captured by the list observation mechanism, which contains the dynamic changes in the resource usage of the target container over a period of time, including update records of key performance indicators such as CPU usage, memory usage, network I / O, and disk I / O.
[0090] When the daemon detects a change in resource usage status from the resource usage data stream, such as a sudden increase in CPU usage or a peak in memory usage, a pre-defined event processing function will be triggered. The event processing function is responsible for analyzing these changes and recording the changed resource usage status for subsequent processing and decision-making.
[0091] The event processing function is a code segment executed inside the daemon process, which is used to respond to resource usage status change events. It determines whether the container has reached the preset accelerated startup conditions or should be restored from the accelerated state by analyzing the information provided in the resource usage data stream, and then records the updated resource usage status or triggers the adjustment of resource limits.
[0092] The monitoring information base is a database or data storage component in the target resource system that stores container operation status and resource usage information. The resource usage status generated by the event processing function will be uploaded to the monitoring information base for the resource controller to read and analyze, and make subsequent resource adjustment decisions.
[0093] It should be noted that when configuring a daemon process (such as sup-daemon), you can establish a target communication interface with the container runtime through the CRI interface and configure the List-watch mechanism to periodically subscribe to resource usage events from the container. sup-daemon will obtain the resource usage events of the target container within the target time period, parse and convert them into resource usage data streams, reflecting changes in the container's resource usage status.
[0094] When the resource usage status in the data stream changes, sup-daemon triggers the event processing function. For example, if the data stream shows that the CPU usage of the container reaches the preset peak value during the acceleration startup duration, the event processing function will record this status change and continue to monitor through the List-watch mechanism until the container resource usage status returns to a stable level or the acceleration startup duration ends.
[0095] The resource usage status report generated by the event processing function will be uploaded to the monitoring information repository of the target resource system. In the Kubernetes environment, this role can be assumed by etcd or other persistent data storage components. The monitoring information repository stores the status and configuration information of the container group instance, including the resource usage of the container, the execution status of the accelerated startup strategy, etc., for real-time decision-making and historical analysis by the resource controller (such as SUP-controller).
[0096] Through the above mechanism, sup-daemon can monitor the resource usage status of the target container in real time and accurately report relevant information to the monitoring information library, providing the resource controller with the real-time data required to dynamically adjust the container resource limits. This not only improves the flexibility and response speed of container resource management, but also ensures the accurate execution of the accelerated startup strategy and the optimization of container operation efficiency.
[0097] Step S104: Based on the resource usage status indicated by the monitoring information and the configuration parameters recorded in the acceleration startup configuration, adjust the system resources of each target container.
[0098] Optionally, step S104 includes: for each target container, comparing the configuration parameters and the resource usage status to obtain a comparison result, wherein the comparison result is used to indicate the difference between the current resource usage demand and the resource configuration of the target container; when the comparison result indicates that the difference exceeds a preset threshold, sending a modification instruction to the target container through the target communication interface, wherein the modification instruction is used to instruct the target container to modify its own configuration parameters based on the accelerated startup strategy; obtaining the resource usage status of the target container after the configuration parameters are modified, and updating the monitoring information library of the target resource system based on the resource usage status.
[0099] Specifically, the difference is the difference between the container resource requirements and the actual resource allocation calculated by the daemon (such as sup-daemon) by comparing the current resource usage status of the container with the configuration parameters recorded in the acceleration startup configuration. The calculation of the difference can help the daemon determine whether the container needs resource adjustment, as well as the direction and degree of adjustment.
[0100] The modification instruction is a control signal generated by the daemon process to adjust the configuration parameters of the target container. It is sent to the container runtime through the target communication interface (i.e., the container runtime interface CRI), thereby adjusting the resource limits of the container. The modification instruction is based on the acceleration startup strategy and the real-time resource usage status of the container to ensure that the container can obtain optimized resource allocation.
[0101] Updating the monitoring information base refers to the process in which the daemon stores the resource usage status report of the target container after the configuration parameters are modified in the monitoring information base. This step ensures the latest and accuracy of the container resource usage status in the monitoring information base, and provides a reliable basis for the resource controller to make subsequent resource adjustment decisions.
[0102] In actual deployment, for each running target container, the sup-daemon daemon process will continuously compare the resource usage status of the container with the configuration parameters recorded in the acceleration startup configuration. For example, it will compare the current CPU usage and memory consumption of the container with the peak resource limit in the configuration and calculate the difference. If the difference exceeds the preset threshold, it means that the current resource demand of the container is not met or exceeds the preset resource limit.
[0103] When the difference exceeds the threshold, sup-daemon generates a modification instruction and sends it to the container runtime through the target communication interface (CRI), instructing the target container to modify its own configuration parameters based on the accelerated startup strategy, for example, to increase the available CPU and memory resources, or to restore to the initial resource limits after the accelerated startup duration ends.
[0104] After the container adjusts the resource configuration according to the modification instructions, the daemon will obtain the resource usage status of the container again, including CPU usage, memory usage and other indicators, to confirm whether the resource adjustment has achieved the expected effect. Then, the daemon will report the updated resource usage status to the monitoring information library to reflect the latest changes in the container resource status.
[0105] For example, suppose a container requires higher CPU and memory resources when it starts. According to the accelerated startup configuration, sup-daemon detects that the difference between the current resource usage status of the container and the configuration parameters exceeds the preset threshold. It will generate a modification instruction and notify the container runtime through the CRI interface to increase the resource limit of the container. After the container resource limit is adjusted, sup-daemon will monitor the resource usage status of the container again to ensure that the container status after the resource adjustment meets the requirements of the accelerated startup policy. If the resource usage status meets the conditions, sup-daemon will report the updated resource usage status to the monitoring information library to complete the closed-loop process of resource adjustment.
[0106] Through the above steps, the present invention can realize dynamic resource adjustment of the target container, ensuring that the container can quickly obtain the required resources during the startup phase, and automatically release excess resources after stable operation, thereby improving resource utilization, reducing startup delays, and optimizing the overall performance of container applications. In addition, by continuously updating the monitoring information library, the system can track the adjustment of container resources in real time, providing detailed data support for subsequent troubleshooting, resource optimization, and policy adjustment.
[0107] Through the above steps S101 to S104, a target container group can be first created in the target resource system, wherein a resource controller and a system daemon are deployed in the target resource system, and the target container group includes N target containers, where N is a positive integer. A configuration identifier is then created for each target container through the resource controller, wherein the configuration identifier is used to indicate whether the target container applies the accelerated startup configuration. The target container to which the accelerated startup configuration has been applied is then monitored through the daemon to obtain monitoring information, wherein the monitoring information is used to record the resource usage status of the target container. Finally, based on the resource usage status indicated by the monitoring information and the configuration parameters recorded in the accelerated startup configuration, system resources are adjusted for each target container.
[0108] In an embodiment of the present invention, a target container group is created in a target resource system, and a configuration identifier is created by a resource controller and a system daemon process is used to monitor the use of container resources, so as to achieve the purpose of dynamically adjusting the resource allocation when the container is running, thereby realizing the technical effects of optimizing resource utilization, accelerating container startup and reducing operating costs. Specifically, whether the container applies the accelerated startup strategy is clarified through the configuration identifier, and the daemon process automatically adjusts the resource limit of the container according to the real-time monitored resource usage status and the preset accelerated startup configuration parameters, so that the container obtains sufficient resources in the startup phase, which accelerates the startup process, and automatically reduces resources after stable operation to avoid resource waste, thereby solving the technical problem in the related technology that the application container cannot be dynamically adjusted in resources, resulting in a mismatch between resource allocation and resource demand.
[0109] The present invention is described below in conjunction with another optional embodiment.
[0110] Embodiment 2
[0111] A system resource adjustment device provided in this embodiment includes multiple implementation units, each implementation unit corresponds to each implementation step in the above-mentioned embodiment 1.
[0112] Figure 2 is a schematic diagram of an optional system resource adjustment device according to an embodiment of the present invention, such as Figure 2 As shown, the device may include: a first creating unit 21 , a second creating unit 22 , a monitoring unit 23 , and an adjusting unit 24 .
[0113] The first creation unit 21 is used to create a target container group in the target resource system, wherein a resource controller and a system daemon are deployed in the target resource system, and the target container group includes N target containers, where N is a positive integer.
[0114] The second creating unit 22 is used to create a configuration identifier for each target container through the resource controller, wherein the configuration identifier is used to indicate whether the target container applies the accelerated startup configuration.
[0115] The monitoring unit 23 is used to monitor the target container to which the accelerated startup configuration has been applied through a daemon process to obtain monitoring information, wherein the monitoring information is used to record the resource usage status of the target container.
[0116] The adjustment unit 24 is used to adjust the system resources of each target container based on the resource usage status indicated by the monitoring information and the configuration parameters recorded in the acceleration startup configuration.
[0117] The above-mentioned system resource adjustment device can first create a target container group in the target resource system through the first creation unit 21, wherein the target resource system deploys a resource controller and a system daemon process, and the target container group includes N target containers, N is a positive integer, and then call the resource controller through the second creation unit 22 to create a configuration identifier for each target container, wherein the configuration identifier is used to indicate whether the target container applies the accelerated startup configuration, and then call the daemon process through the monitoring unit 23 to monitor the target container to which the accelerated startup configuration has been applied to obtain monitoring information, wherein the monitoring information is used to record the resource usage status of the target container, and finally adjust the system resources of each target container based on the resource usage status indicated by the monitoring information and the configuration parameters recorded in the accelerated startup configuration through the adjustment unit 24.
[0118] In an embodiment of the present invention, a target container group is created in a target resource system, and a configuration identifier is created by a resource controller and a system daemon is used to monitor the use of container resources, so as to achieve the purpose of dynamically adjusting the resource allocation of the container at runtime, thereby achieving the technical effects of optimizing resource utilization, accelerating container startup and reducing operating costs. Specifically, the configuration identifier is used to clarify whether the container applies the accelerated startup strategy. The daemon automatically adjusts the resource limit of the container according to the real-time monitored resource usage status and the preset accelerated startup configuration parameters, so that the container obtains sufficient resources in the startup phase, which accelerates the startup process. Moreover, after stable operation, the resources are automatically reduced to avoid resource waste, thereby solving the technical problem in the related technology that the application container cannot be dynamically adjusted in resources, resulting in a mismatch between resource allocation and resource demand.
[0119] Optionally, the first creation unit includes: a first acquisition module, used to acquire an accelerated startup configuration, wherein the accelerated startup configuration records at least: an initial resource limit, a peak resource limit, and a duration of the accelerated startup; a first creation module, used to create a container group template based on the configuration parameters recorded in the accelerated startup configuration, wherein the resource request limit of the container is set in the container group template based on the initial resource limit, the peak resource limit, and the duration of the accelerated startup; a second creation module, used to create a container group instance based on the container group template to obtain a target container group; an allocation module, used to allocate the target container in the target container group to each node of the target resource system to complete the container deployment.
[0120] Optionally, the system resource adjustment device also includes: a determination module, used to determine M computing nodes in the container orchestration system, where M is a positive integer; a first generation module, used to register the computing nodes as system nodes of the target resource system, and generate the target resource system based on the M system nodes; a deployment module, used to deploy a resource controller and a system daemon in each system node, wherein the resource controller is used to adjust the acceleration startup configuration, and the system daemon is used to adjust the resource limit of the target container based on the acceleration startup configuration.
[0121] Optionally, the second creation unit includes: a parsing module, which is used to receive the accelerated startup policy through the resource controller, and parse the accelerated startup policy to obtain a parsing result, wherein the parsing result at least includes an accelerated startup object and an accelerated startup parameter; a second generation module, which is used to generate an accelerated startup configuration in the target resource system based on the parsing result; a third generation module, which is used to generate a configuration identifier for each target container based on the accelerated startup configuration, wherein the configuration identifier is used to edit whether the container applies the accelerated startup policy; a storage module, which is used to store the configuration identifier in a metadata database of the target resource system, wherein the metadata database is used to record status information and configuration information of the container group instance.
[0122] Optionally, the monitoring unit includes: a running module, used to run a daemon process, wherein a target communication interface is reserved in the daemon process, and the target communication interface is used to communicate with the target container during the operation of the target container; a second acquisition module, used to obtain the resource usage status of the target container during the operation through the target communication interface, wherein the resource usage status includes at least: CPU usage status and memory usage status; a fourth generation module, used to generate a resource usage status report based on the resource usage status to obtain monitoring information.
[0123] Optionally, the second acquisition module includes: a configuration submodule, used to configure a list observation mechanism for the target communication interface, wherein the list observation mechanism is used to periodically subscribe to resource usage events to the target container; an analysis submodule, used to obtain the resource usage events of the target container within the target time period based on the list observation mechanism, and analyze the resource usage events to obtain a resource usage data stream; a trigger submodule, used to trigger an event processing function through the list observation mechanism when the resource usage data stream indicates that the resource usage status has changed, wherein the event processing function is used to record the changed resource usage status; an upload submodule, used to upload the resource usage status generated by the event processing function to the monitoring information library of the target resource system.
[0124] Optionally, the adjustment unit includes: a comparison module, used to compare the configuration parameters and resource usage status of each target container to obtain a comparison result, wherein the comparison result is used to indicate the difference between the current resource usage demand and the resource configuration of the target container; a sending module, used to send a modification instruction to the target container through the target communication interface when the comparison result indicates that the difference exceeds a preset threshold, wherein the modification instruction is used to instruct the target container to modify its own configuration parameters based on the accelerated startup strategy; an updating module, used to obtain the resource usage status of the target container after the configuration parameters are modified, and update the monitoring information library of the target resource system based on the resource usage status.
[0125] The above-mentioned system resource adjustment device may also include a processor and a memory. The above-mentioned first creation unit 21, second creation unit 22, monitoring unit 23, adjustment unit 24, etc. are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to realize corresponding functions.
[0126] The processor includes a kernel, and the kernel retrieves the corresponding program unit from the memory. One or more kernels can be set, and the target container to which the accelerated startup configuration has been applied is monitored through the daemon process by adjusting the kernel parameters to obtain monitoring information, wherein the monitoring information is used to record the resource usage status of the target container, and based on the resource usage status indicated by the monitoring information and the configuration parameters recorded in the accelerated startup configuration, the system resources of each target container are adjusted.
[0127] The above-mentioned memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one storage chip.
[0128] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing a program that is initialized with the following method steps: creating a target container group in a target resource system, wherein a resource controller and a system daemon are deployed in the target resource system, and the target container group includes N target containers, where N is a positive integer; creating a configuration identifier for each target container through the resource controller, wherein the configuration identifier is used to indicate whether the target container applies an accelerated startup configuration; monitoring the target container to which the accelerated startup configuration has been applied through the daemon to obtain monitoring information, wherein the monitoring information is used to record the resource usage status of the target container; and adjusting the system resources of each target container based on the resource usage status indicated by the monitoring information and the configuration parameters recorded in the accelerated startup configuration.
[0129] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute a method for adjusting system resources of any one of the above-mentioned embodiments one.
[0130] According to another aspect of an embodiment of the present invention, there is also provided an electronic device, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by one or more processors, the one or more processors implement the system resource adjustment method of any one of the above-mentioned embodiments one.
[0131] Figure 3 1 is a hardware structure block diagram of an electronic device (or mobile device) for executing a method for adjusting system resources according to an embodiment of the present invention. Figure 3 As shown, the electronic device may include one or more ( Figure 3 302a, 302b, ..., 302n are used to illustrate) processor (the processor may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 304 for storing data. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a keyboard, a power supply and / or a camera. It can be understood by those skilled in the art that Figure 3 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 3 More or fewer components as shown, or with Figure 3 Different configurations are shown.
[0132] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.
[0133] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.
[0134] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.
[0135] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.
[0136] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.
[0137] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.
[0138] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.
Claims
1. A method for adjusting system resources, characterized in that: include: Create a target container group in a target resource system, wherein a resource controller and a system daemon are deployed in the target resource system, and the target container group includes N target containers, where N is a positive integer; Creating a configuration identifier for each target container by the resource controller, wherein the configuration identifier is used to indicate whether the target container applies an accelerated startup configuration; Monitoring the target container to which the accelerated startup configuration has been applied through the daemon process to obtain monitoring information, wherein the monitoring information is used to record the resource usage status of the target container; Based on the resource usage status indicated by the monitoring information and the configuration parameters recorded in the accelerated startup configuration, system resources are adjusted for each target container.
2. The adjustment method according to claim 1, characterized in that: The steps to create a target container group in the target resource system include: Acquire the accelerated startup configuration, wherein the accelerated startup configuration at least records: initial resource limit, peak resource limit and accelerated startup duration; Creating a container group template based on the configuration parameters recorded in the accelerated startup configuration, wherein the container group template sets a resource request limit for the container based on the initial resource limit, the peak resource limit, and the accelerated startup duration; Creating a container group instance based on the container group template to obtain the target container group; The target container in the target container group is allocated to each node of the target resource system to complete container deployment.
3. The adjustment method according to claim 1, characterized in that: The target resource system is obtained by the following steps: Determine M computing nodes in the container orchestration system, where M is a positive integer; Registering the computing node as a system node of the target resource system, and generating the target resource system based on M system nodes; The resource controller and the system daemon are deployed in each of the system nodes, wherein the resource controller is used to adjust the accelerated startup configuration, and the system daemon is used to adjust the resource limit of the target container based on the accelerated startup configuration.
4. The adjustment method according to claim 1, characterized in that: The step of creating a configuration identifier for each target container by the resource controller includes: Receiving the accelerated startup policy through the resource controller, and parsing the accelerated startup policy to obtain a parsing result, wherein the parsing result at least includes an accelerated startup object and an accelerated startup parameter; generating the acceleration startup configuration in the target resource system based on the parsing result; Generate the configuration identifier for each target container based on the accelerated startup configuration, wherein the configuration identifier is used to edit whether the container applies the accelerated startup policy; The configuration identifier is stored in a metadata database of the target resource system, wherein the metadata database is used to record status information and configuration information of the container group instance.
5. The adjustment method according to claim 1, characterized in that: The step of monitoring the target container to which the accelerated startup configuration has been applied through the daemon process to obtain monitoring information includes: Running the daemon process, wherein a target communication interface is reserved in the daemon process, and the target communication interface is used to communicate with the target container during the running of the target container; Acquiring, through the target communication interface, a resource usage status of the target container during operation, wherein the resource usage status includes at least: a CPU usage status and a memory usage status; A resource usage status report is generated based on the resource usage status to obtain the monitoring information.
6. The adjustment method according to claim 5, characterized in that: The step of obtaining the resource usage status of the target container during operation through the target communication interface includes: configuring a list observation mechanism for the target communication interface, wherein the list observation mechanism is used to periodically subscribe to resource usage events from the target container; Acquire resource usage events of the target container within a target time period based on the list observation mechanism, and analyze the resource usage events to obtain a resource usage data stream; When the resource usage data stream indicates that the resource usage status has changed, triggering an event processing function through the list observation mechanism, wherein the event processing function is used to record the changed resource usage status; The resource usage status generated by the event processing function is uploaded to the monitoring information library of the target resource system.
7. The adjustment method according to claim 1, characterized in that: The step of adjusting the system resources of each target container based on the resource usage status indicated by the monitoring information and the configuration parameters recorded in the acceleration startup configuration includes: For each of the target containers, compare the configuration parameters with the resource usage status to obtain a comparison result, wherein the comparison result is used to indicate the difference between the current resource usage requirement and the resource configuration of the target container; When the comparison result indicates that the difference exceeds a preset threshold, sending a modification instruction to the target container through a target communication interface, wherein the modification instruction is used to instruct the target container to modify its own configuration parameters based on the accelerated startup strategy; The resource usage status of the target container after the configuration parameters are modified is obtained, and the monitoring information library of the target resource system is updated based on the resource usage status.
8. A system resource adjustment device, characterized in that: include: A first creation unit is used to create a target container group in a target resource system, wherein a resource controller and a system daemon are deployed in the target resource system, and the target container group includes N target containers, where N is a positive integer; A second creation unit, configured to create a configuration identifier for each target container through the resource controller, wherein the configuration identifier is used to indicate whether the target container applies an accelerated startup configuration; A monitoring unit, configured to monitor the target container to which the accelerated startup configuration has been applied through the daemon process to obtain monitoring information, wherein the monitoring information is used to record the resource usage status of the target container; An adjustment unit is used to adjust the system resources of each target container based on the resource usage status indicated by the monitoring information and the configuration parameters recorded in the accelerated startup configuration.
9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located is controlled to execute the method for adjusting system resources according to any one of claims 1 to 7.
10. An electronic device, characterized in that: It includes one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the system resource adjustment method described in any one of claims 1 to 7.