Control methods, equipment and storage media for container management systems

Abstract

This application discloses a control method, device, and storage medium for a container management system. The control method for the container management system includes: responding to a triggered operation in response to dynamic resource demand; parsing the operation type and content of the triggered operation; obtaining the initial resource quota allocated to the tenant during registration; determining the change in resource demand corresponding to the triggered operation based on the operation type and content; substituting the used resource amount, initial resource quota, and change in resource demand into a preset resource allocation formula to calculate the tenant's real-time resource allocation; adjusting the tenant's resource usage quota based on the real-time resource allocation and synchronously updating the resource scheduling strategy of the cluster nodes. This application achieves the technical effect of dynamic resource scheduling for tenants.

Description

Technical Field

[0001] This application relates to the field of container management technology, and in particular to a control method, device and storage medium for a container management system. Background Technology

[0002] Kubernetes cluster resource management refers to a series of operations that allocate, schedule, monitor, and limit computing, storage, and network resources within the cluster. The core objectives are to ensure efficient resource utilization, avoid resource contention, guarantee stable application operation, and achieve fair sharing of cluster resources among multiple tenants and teams. The most critical manageable resources in Kubernetes are computing resources such as CPU and memory. Additionally, it supports extended resources such as GPUs, FPGAs (Field-Programmable Gate Arrays), and storage IOPS (Input / Output Operations Per Second).

[0003] However, when multiple tenants share cluster resources, traditional static resource limitation solutions are prone to causing some tenants to over-consume CPU, memory, GPU and other resources in scenarios with dynamic business needs, resulting in limited operation of other tenant applications. Summary of the Invention

[0004] The main purpose of this application is to provide a control method, device and storage medium for a container management system, which aims to solve the technical problem that in dynamic business demand scenarios, some tenants may over-occupy resources, resulting in limited operation of other tenant applications.

[0005] To achieve the above objectives, this application provides a control method for a container management system, the control method for the container management system comprising:

[0006] In response to a triggering operation for dynamic resource demand, the operation type and operation content of the triggering operation are parsed. The operation type includes deploying a new application, performing scaling operations on an existing application, updating the application image version, and adjusting application runtime resource request parameters.

[0007] Obtain the initial resource quota allocated when the tenant registers for the triggering operation. The initial resource quota includes a first resource allocation, a second resource allocation, a third resource allocation, and a fourth resource allocation.

[0008] Based on the operation type and the operation content, determine the change in resource demand corresponding to the triggering operation;

[0009] Substitute the used resources, initial resource quota, and changes in resource demand into the preset resource allocation formula to calculate the real-time resource allocation for the tenant.

[0010] Adjust the tenant's resource usage quota based on the real-time resource allocation and update the cluster node's resource scheduling strategy synchronously.

[0011] In one embodiment, the step of resolving the operation type and operation content of the trigger operation in response to dynamic resource demand includes:

[0012] If the operation type is to deploy a new application, the operation content is parsed to obtain the preset number of replicas, the CPU request amount, memory request amount, GPU request amount, and storage request amount required per replica;

[0013] If the operation type is to perform a scaling up or down operation on an existing application, the operation content is parsed to obtain the current number of replicas, the target number of replicas, and the fixed resource configuration information of a single replica. The fixed resource configuration information includes the baseline amount of CPU, memory, GPU, and storage occupied by a single replica.

[0014] If the operation type is to update the application image version, the operation content is parsed to obtain the resource requirement parameters of the current image version and the resource requirement parameters of the new version image. The resource requirement parameters include the CPU limit, memory limit, GPU utilization threshold and storage IOPS requirement.

[0015] If the operation type is to adjust the application runtime resource request parameters, the operation content is parsed to obtain the resource type to be adjusted and the corresponding request volume adjustment value. The resource type includes at least one of CPU, memory, GPU, and storage.

[0016] In one embodiment, the first resource is CPU, the second resource is memory, the third resource is GPU, and the fourth resource is storage. Before the step of obtaining the initial resource quota allocated when the tenant registers the corresponding to the triggering operation, the following steps are included:

[0017] The system receives a tenant's registration request, parses the registration request to obtain tenant type information, business scenario description, and estimated resource requirements. The tenant type information includes individual tenants, enterprise tenants, or priority tenants, and the business scenario description includes compute-intensive, storage-intensive, or network-intensive scenarios.

[0018] Based on the preset resource quota benchmark table, the basic quota coefficient is determined in combination with the tenant type information. Among them, the basic quota coefficient of enterprise tenants is higher than that of individual tenants, and the basic quota coefficient of priority tenants is higher than that of ordinary tenants of the same type.

[0019] The corresponding resource weight matrix is ​​matched according to the business scenario description. In the computing-intensive scenario, the weight of CPU and GPU is higher than that of memory and storage. In the storage-intensive scenario, the weight of storage is higher than that of CPU, GPU and memory.

[0020] By combining the basic quota coefficient, resource weight matrix and estimated resource demand, the first resource allocation, second resource allocation, third resource allocation and fourth resource allocation are calculated to determine the tenant's initial resource quota;

[0021] The initial resource quota is associated with the tenant identifier and stored, and a resource upper limit threshold is set for the tenant. The resource upper limit threshold is a preset multiple of the initial resource quota and does not exceed a preset percentage of the total available resources of the cluster.

[0022] In one embodiment, the step of determining the change in resource demand corresponding to the triggering operation based on the operation type and the operation content includes:

[0023] If the operation type is to deploy a new application, the changes in resource requirements for CPU, memory, GPU and storage are calculated based on the parsed CPU request volume, memory request volume, GPU request volume, storage request volume and preset number of replicas required for a single replica.

[0024] If the operation type is to perform a scaling up or down operation on an existing application, the resource requirement change for each resource type is calculated based on the difference between the current number of replicas and the target number of replicas obtained from parsing, combined with the fixed resource configuration information of a single replica.

[0025] If the operation type is to update the application image version, calculate the difference in resource requirement parameters between the new version image and the current image version, and use the difference as the change in resource requirement for each resource type.

[0026] If the operation type is to adjust the application runtime resource request parameters, the parsed adjustment values ​​of the request quantity for each resource type will be directly used as the corresponding resource demand change.

[0027] In one embodiment, the real-time resource allocation is obtained through initial resource quota, used resource amount, resource type weight, resource demand change amount, and tenant priority factor.

[0028] In one embodiment, after the step of adjusting the tenant's resource usage quota according to the real-time resource allocation and synchronously updating the cluster node's resource scheduling policy, the method further includes:

[0029] For CPU, memory, GPU, and storage, calculate the ratio of used resources to initial resource quota to obtain the utilization rate of each resource type;

[0030] Based on the preset health assessment model, the utilization rate of each resource type is mapped to the corresponding health value;

[0031] Determine the health weights for each resource type, with CPU and GPU having higher weights than memory and storage;

[0032] The overall health of a tenant is calculated by using the health values ​​of each resource type and the configured health weights.

[0033] In one embodiment, after the step of adjusting the tenant's resource usage quota according to the real-time resource allocation and synchronously updating the cluster node's resource scheduling policy, the method further includes:

[0034] Based on the initial resource quota corresponding to the GPU, determine the initial GPU resource limits for computing GPUs, rendering GPUs, and general-purpose GPUs respectively;

[0035] Obtain the tenant's initial GPU resource limit usage;

[0036] Extract the daily peak utilization, average utilization, and resource request frequency corresponding to the tenant's historical GPU resource consumption data, and collect the current GPU resource usage and request queue length;

[0037] A dynamic correction factor is generated based on daily peak utilization, average utilization, resource request frequency, current GPU resource usage, and request queue length.

[0038] Adjust tenant GPU resource limits based on dynamic correction factors.

[0039] In one embodiment, before the step of resolving the operation type and operation content of the trigger operation in response to dynamic resource demand, the method includes:

[0040] In response to a virtual cluster isolation command, the virtual cluster instance of the tenant from which the virtual cluster isolation command originates is determined. The virtual cluster instance includes a virtual API server, a virtual controller manager, and a virtual scheduler. The virtual cluster instance and the physical cluster achieve isolated scheduling of container resources through a resource mapping layer.

[0041] Deploy the virtual control plane components in a dedicated namespace of the underlying physical Kubernetes cluster;

[0042] The step of resolving the operation type and operation content of the trigger operation in response to dynamic resource demand includes:

[0043] In response to a tap operation on the virtual control plane component, determine the API interface;

[0044] If the API interface belongs to the virtual cluster instance associated with the tenant's tenant identifier, the step of parsing the operation type and operation content of the triggering operation is executed.

[0045] In addition, to achieve the above objectives, this application also provides a control device for a container management system, the control device for the container management system comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the control method for the container management system as described above.

[0046] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium, on which a program implementing a control method for a container management system is stored. The program implementing the control method for a container management system is executed by a processor to implement the steps of the control method for a container management system as described above.

[0047] This application provides a control method for a container management system. First, in response to a triggering operation based on dynamic resource demand, the method parses the operation type and content of the triggering operation. The operation type includes deploying a new application, performing scaling operations on an existing application, updating the application image version, and adjusting application runtime resource request parameters. The method then obtains the initial resource quota allocated to the tenant during registration, which includes a first resource allocation, a second resource allocation, a third resource allocation, and a fourth resource allocation. Based on the operation type and content, the method determines the change in resource demand corresponding to the triggering operation. Substituting the used resources, the initial resource quota, and the change in resource demand into a preset resource allocation formula, the method calculates the tenant's real-time resource allocation. Based on the real-time resource allocation, the method adjusts the tenant's resource usage quota and synchronously updates the resource scheduling strategy of the cluster nodes. In other words, this application determines the change in resource demand by distinguishing different operation types and content, then combines the change in resource demand with the initial resource quota allocated during tenant registration to calculate the tenant's real-time resource allocation, thereby adjusting the resource scheduling strategy of the cluster nodes and the tenant's resource usage quota. This solution addresses the technical issue in scenarios with dynamic business needs of tenants where some tenants excessively consume resources, leading to limitations on the operation of other tenant applications. It achieves the technical effect of dynamic resource scheduling for tenants. Attached Figure Description

[0048] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0049] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 This is a flowchart illustrating an embodiment of the control method for the container management system of this application.

[0051] Figure 2 This is a flowchart illustrating Embodiment Seven of the control method for the container management system of this application.

[0052] Figure 3 This is a flowchart illustrating an eighth embodiment of the control method for the container management system of this application.

[0053] Figure 4 This is a schematic diagram of the hardware architecture involved in the control device embodiment of the container management system of this application.

[0054] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0055] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0056] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0057] Currently, when multiple tenants share cluster resources, traditional static resource limitation solutions are prone to causing some tenants to excessively consume CPU, memory, GPU and other resources in scenarios with dynamic business needs, resulting in limited operation of other tenant applications.

[0058] The main solution of this application is to determine the change in resource demand by differentiating different operation types and content. Then, by combining the change in resource demand with the initial resource quota allocated to the tenant during registration, the real-time resource allocation for the tenant is calculated. This allows for adjustments to the resource scheduling strategy of cluster nodes and the resource usage quota for each tenant. This solves the technical problem in scenarios with dynamic business needs of tenants, where some tenants excessively consume CPU, memory, GPU, and other resources, leading to limitations in the operation of other tenant applications. It achieves the technical effect of dynamic resource scheduling for tenants.

[0059] It should be noted that the executing entity in this embodiment can be a container management system, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a control device for a container management system capable of performing the above functions. This embodiment does not specifically limit the specific implementation. The following uses a container management system as the executing entity as an example to describe this embodiment and the following embodiments.

[0060] Based on this, Embodiment 1 of this application proposes a control method for a container management system. Please refer to... Figure 1 The control method of the container management system includes steps S10 to S50:

[0061] Step S10: In response to the triggering operation of dynamic resource demand, parse the operation type and operation content of the triggering operation, wherein the operation type includes deploying a new application, performing scaling operations on an existing application, updating the application image version, and adjusting the application runtime resource request parameters.

[0062] In this embodiment, the triggering operation for dynamic resource demand refers to the operational behavior that causes a tenant's resource demand to change during the use of the container management system. The operation type is a classification identifier for the triggering operation, used to distinguish different types of resource demand changes. The operation content is the specific information contained in the triggering operation, such as the application identifier and resource parameters involved in the operation.

[0063] As an optional implementation, the container management system collects tenant operation requests in real time. When an operation that meets preset trigger conditions is detected, a parsing process is initiated. For operations deploying new applications, the system parses out the application name, the image used, the required number of replicas, and the specific request value for each resource. For operations scaling up or down replicas, the system parses out the target application ID, the current number of replicas, and the target number of replicas. For operations updating application image versions, the system parses out the application ID, the current image version, and the new image version. For operations adjusting application runtime resource request parameters, the system parses out the application ID, the type of resource to be adjusted, and the specific adjusted value.

[0064] As an alternative implementation, the container management system includes a dedicated operation log collection module that periodically analyzes collected tenant operation logs and filters out records triggered by dynamic resource demands. Using preset parsing rules, the system extracts the operation type and content from the log records. For example, identifying a record like "Deploy application: Application A, Image X, Replica count 2, CPU request 1 core" from the logs reveals the operation type to be deploying a new application, and the operation content to include information such as Application A, Image X, Replica count 2, and CPU request 1 core.

[0065] Step S20: Obtain the initial resource quota allocated when the tenant registers the corresponding tenant for the triggering operation. The initial resource quota includes a first resource allocation amount, a second resource allocation amount, a third resource allocation amount, and a fourth resource allocation amount.

[0066] In this embodiment, the initial resource quota is the initial amount of various resources allocated to a tenant by the system based on the tenant's relevant information when the tenant registers with the container management system. The first resource allocation, the second resource allocation, the third resource allocation, and the fourth resource allocation correspond to the allocation quantities of different types of resources, such as the allocation quantities of CPU, memory, GPU, and storage, respectively.

[0067] As an optional implementation, after tenant registration, the container management system associates the allocated initial resource quota with the tenant ID and stores it in the database. When needed, it directly queries the database for the tenant's initial resource quota record based on the tenant ID corresponding to the triggered operation, and then extracts the first to fourth resource allocation amounts.

[0068] As an alternative implementation, the container management system includes a resource quota caching module that caches the initial resource quotas of frequently accessed tenants in memory. When the quota is needed, the system first checks if the initial resource quota for that tenant exists in the cache. If it does, it retrieves it directly from the cache; otherwise, it queries the database and updates the cache with the query results for faster access in the future.

[0069] Step S30: Determine the change in resource demand corresponding to the triggering operation based on the operation type and the operation content.

[0070] In this embodiment, the change in resource demand refers to the amount by which the tenant's demand for various resources changes due to the execution of the triggering operation. It can be positive or negative, with a positive value indicating an increase in demand and a negative value indicating a decrease in demand.

[0071] As an optional implementation, corresponding calculation rules are preset for different operation types. For deploying a new application, the new resource requirements for various types of resources are calculated based on the single-replica resource request quantity and the number of replicas in the operation content, i.e., resource requirement change = single-replica resource request quantity × number of replicas; for scaling up or down replicas, the resource requirement change is calculated based on the difference between the target number of replicas and the current number of replicas and the single-replica resource quantity, i.e., (target number of replicas - current number of replicas) × single-replica resource quantity; for updating the application image version, the difference in resource requirements between the new image and the current image is calculated as the resource requirement change; for adjusting application runtime resource request parameters, the difference between the adjusted parameter value and the original parameter value is used as the resource requirement change.

[0072] As an alternative implementation, the container management system sets up a resource demand assessment model. This model combines operation type, operation content, and historical resource usage data to estimate changes in resource demand. For example, for deploying a new application, the model not only considers the resource request volume per replica and the number of replicas, but also refers to the actual resource consumption of similar applications in similar scenarios to correct the calculated changes in resource demand, resulting in a more realistic outcome.

[0073] Step S40: Substitute the used resource amount, initial resource quota, and changes in resource demand into the preset resource allocation formula to calculate the real-time resource allocation for the tenant.

[0074] In this embodiment, the amount of resources used refers to the quantity of various types of resources currently occupied by the tenant. The real-time resource allocation amount refers to the real-time quota of various types of resources currently allocated to the tenant, as determined by the container management system after calculation. The preset resource allocation formula is a mathematical formula used to calculate the real-time resource allocation amount, which comprehensively considers factors such as the amount of resources used, the initial resource quota, and changes in resource demand.

[0075] As an optional implementation, the preset resource allocation formula is: Real-time resource allocation = Initial resource quota - Used resources + Changes in resource demand. During calculation, the corresponding data for each resource type (CPU, memory, GPU, storage, etc.) is substituted into the formula to obtain the real-time resource allocation for each resource type. Simultaneously, an upper limit is set for the real-time resource allocation to ensure it does not exceed the maximum resource limit set by the cluster for that tenant.

[0076] As an alternative implementation, the preset resource allocation formula is: Real-time resource allocation = (Initial resource quota - Used resource amount) × Resource type weight + Resource demand change × Tenant priority factor. Here, the resource type weight is set according to the importance of the resource, and the tenant priority factor is determined according to the tenant's level. During calculation, each resource type is substituted into the formula to obtain the real-time resource allocation for each resource type, ensuring that it does not exceed the maximum resource limit and is not less than the currently necessary resource amount.

[0077] Step S50: Adjust the tenant's resource usage quota according to the real-time resource allocation amount, and synchronously update the resource scheduling strategy of the cluster nodes.

[0078] In this embodiment, resource usage quota refers to the maximum limit of various resources that the container management system allows tenants to use. Cluster node resource scheduling strategy refers to the rules and methods followed by the container management system when allocating cluster node resources to containers.

[0079] As an optional implementation, the container management system directly modifies the resource usage quota record corresponding to the tenant based on the calculated real-time resource allocation, updating the original quota value to the real-time resource allocation. Simultaneously, a new resource scheduling strategy is generated. This strategy prioritizes scheduling the tenant's containers to nodes with sufficient remaining resources to meet the real-time resource allocation requirements, and considers the load balancing of nodes during the scheduling process.

[0080] As an alternative implementation, the container management system performs a pre-verification before adjusting resource usage quotas to check whether the adjusted quotas will adversely affect the overall resource allocation of the cluster. If the verification passes, the adjustment operation is executed. For the resource scheduling strategy of cluster nodes, a dynamic update mechanism is adopted. Based on the real-time resource allocation and node resource status, the scheduling weights are periodically recalculated to enable the scheduling strategy to adapt to resource changes and improve resource utilization.

[0081] For example, when an enterprise tenant registers in the container management system, the initial resource allocation is as follows: 4 CPU cores (first allocation), 8GB memory (second allocation), 1 GPU (third allocation), and 100GB storage (fourth allocation). This tenant triggers a new application deployment operation: deploying application B using image Y with 2 replicas. Each replica requires 1 CPU core, 2GB memory, 0.5 GPUs, and 10GB storage. After the system parses the operation type as "deploying a new application" and the corresponding operation content, it obtains the tenant's initial resource allocation. Based on the operation type and content, the resource requirement change is calculated to be 2 CPU cores, 4GB memory, 1 GPU, and 20GB storage. Assuming the tenant currently uses 1 CPU core, 2GB memory, 0.3 GPUs, and 15GB storage, the real-time resource allocation is calculated using the formula: Real-time resource allocation = Initial resource allocation - Used resources + Resource requirement change, resulting in a real-time resource allocation of 5 CPU cores, 10GB memory, 1.7 GPUs, and 105GB storage. The system adjusts the tenant's resource usage quota based on the real-time resource allocation and updates the cluster node scheduling policy to schedule application B's container to a node with sufficient remaining resources.

[0082] This embodiment responds to tenants' dynamic resource demand triggering operations, accurately parses operation information, and calculates real-time resource allocation by combining initial resource quotas, used resource amounts, and changes in resource demand. It then adjusts resource usage quotas and scheduling strategies, achieving dynamic management of tenant resources. This enables timely fulfillment of tenants' resource demand changes caused by business operations, improving resource utilization efficiency and the flexibility of the container management system.

[0083] Based on any of the above embodiments, in Embodiment 2 of this application, step S10 includes:

[0084] Step S11: If the operation type is to deploy a new application, parse the operation content to obtain the preset number of replicas, the amount of CPU requests, memory requests, GPU requests, and storage requests required per replica.

[0085] In this embodiment, the preset number of replicas refers to the number of container instances that a tenant pre-sets when deploying a new application. The CPU request required per replica is the amount of CPU resources that a single container instance needs to request when running. The memory request required per replica is the amount of memory resources that a single container instance needs to request when running. The GPU request required per replica is the amount of GPU resources that a single container instance needs to request when running (if the application requires GPU support). The storage request required per replica is the amount of storage resources that a single container instance needs to request when running.

[0086] As an optional implementation, the container management system provides a visual deployment interface. Tenants fill in relevant information for deploying new applications, including the preset number of replicas and the CPU, memory, GPU, and storage requests per replica. The system directly reads these input values ​​through the interface form parsing module, using them as the parsed operation content.

[0087] As an alternative implementation, tenants submit requests to deploy new applications via an API interface. The request parameters are transmitted in JSON format, containing fields for the preset number of replicas and the request quantity for each resource. The system's API parsing module parses the JSON parameters, extracts the corresponding values, and completes the parsing of the operation content.

[0088] Step S12: If the operation type is to perform a scaling up / down operation on an existing application, parse the operation content to obtain the current number of replicas, the target number of replicas, and the fixed resource configuration information of a single replica. The fixed resource configuration information includes the baseline amount of CPU, memory, GPU, and storage occupied by a single replica.

[0089] In this embodiment, the current replica count refers to the number of container instances currently running for the existing application before the replica scaling operation is executed. The target replica count refers to the number of container instances that the tenant expects to achieve through the replica scaling operation. The fixed resource configuration information for a single replica refers to the baseline values ​​of various resources that are fixedly occupied during the operation of a single container instance, and is the basis for calculating the changes in resource requirements during the replica scaling operation.

[0090] As an optional implementation, the system queries the application management database for the current running information of the existing application to obtain the current number of replicas and the fixed resource configuration information of each replica. Simultaneously, it reads the target number of replicas carried in the scaling operation instructions submitted by the tenant and integrates these to obtain the complete operation details.

[0091] As another optional implementation, the system listens for application scaling events. When a scaling operation is detected, a data collection process is triggered. By interacting with the container runtime interface, the current number of replicas and the fixed configuration information of single replica resources are obtained. Then, the target number of replicas is parsed from the operation instructions to complete the parsing of the operation content.

[0092] Step S13: If the operation type is to update the application image version, parse the operation content to obtain the resource requirement parameters of the current image version and the resource requirement parameters of the new version image. The resource requirement parameters include the CPU limit, memory limit, GPU utilization threshold and storage IOPS requirement.

[0093] In this embodiment, the resource requirement parameters of the current image version refer to the resource requirement limits of the image currently used by the application at runtime. The resource requirement parameters of the new version image refer to the resource requirement limits of the image to be updated at runtime. The CPU limit refers to the maximum amount of CPU resources allowed to be used by the container at runtime. The memory limit refers to the maximum amount of memory resources allowed to be used by the container at runtime. The GPU utilization threshold refers to the maximum percentage of GPU resources that can be used by the container. The storage IOPS requirement refers to the number of input / output operations per second that the container requires from the storage device.

[0094] As an optional implementation, the system retrieves metadata information for the current image version and the new version image from the image repository. This metadata includes descriptions of resource requirement parameters. The metadata parsing module extracts parameters such as CPU limit, memory limit, GPU utilization threshold, and storage IOPS requirement as the parsed operational content.

[0095] As an alternative implementation, when a tenant submits a request to update the application image version, the system requires the tenant to upload a resource requirement configuration file for the new version image. The system parses this configuration file and combines it with the resource requirement parameters of the current image version retrieved from the system to obtain the operation content.

[0096] Step S14: If the operation type is to adjust the application runtime resource request parameters, parse the operation content to obtain the resource type to be adjusted and the corresponding request quantity adjustment value, wherein the resource type includes at least one of CPU, memory, GPU and storage.

[0097] In this embodiment, the resource type to be adjusted refers to the type of resource that the tenant wants to change its request volume for, such as CPU or memory. The request volume adjustment value refers to the specific numerical value that the tenant wants to increase or decrease in the request volume for this resource type; a positive number indicates an increase, and a negative number indicates a decrease.

[0098] As an optional implementation, tenants select the resource type to be adjusted and enter the corresponding adjustment value at the application runtime resource adjustment interface. The system's interface interaction module records these selections and inputs, directly parsing them into the resource type to be adjusted and the request volume adjustment value.

[0099] As an alternative implementation, tenants submit resource request parameter adjustment commands via command-line tools. These commands include the resource type and adjustment value parameters. The system's command parsing module parses the commands, extracting the corresponding resource type and request quantity adjustment value as the operation content.

[0100] For example, the tenant performed four operations: First, deploying a new application by inputting a preset replica count of 2, a single replica CPU request of 1 core, a memory request of 2GB, a GPU request of 0.5 cards, and a storage request of 10GB through a visual interface. The system parsed the corresponding operation content. Second, performing a scaling operation on an existing application. The system retrieved the current replica count of 3 and the fixed resource configuration of a single replica (1 CPU core, 2GB memory, etc.) from the application management database and parsed the target replica count of 5 in the tenant's instruction. Third, updating the application image version. The system parsed the current image's maximum CPU cores of 2 and maximum memory of 4GB from the image repository metadata, as well as the corresponding parameters of the new version image. Fourth, adjusting the application runtime resource request parameters. The tenant selected the CPU type on the interface and input an adjustment value of 0.5 cores. The system parsed the resource type to be adjusted as CPU and the request adjustment value as 0.5 cores.

[0101] This embodiment accurately extracts key resource information from various operation contents by formulating corresponding parsing methods for different operation types. This provides a precise data foundation for subsequent calculation of changes in resource demand and improves the accuracy and efficiency of the container management system in responding to tenants' dynamic resource demands.

[0102] Based on any of the above embodiments, in Embodiment 2 of this application, before step S20, the following is included:

[0103] Step S21: Receive the tenant's registration request, parse the registration request to obtain tenant type information, business scenario description and estimated resource requirements. The tenant type information includes individual tenants, enterprise tenants or priority tenants, and the business scenario description includes compute-intensive, storage-intensive or network-intensive.

[0104] In this embodiment, tenant type information is a classification identifier used to distinguish tenant attributes; different types of tenants will have different resource allocations. The business scenario description is a description of the tenant's application operation scenario, used to determine the focus of resource allocation. Estimated resource requirements are the approximate demand for various resources estimated by the tenant based on its own business situation. The first resource is CPU, the second resource is memory, the third resource is GPU, and the fourth resource is storage.

[0105] As an optional implementation, the container management system provides an online registration form, which includes options for tenant type selection, a business scenario description input box, and an estimated resource requirement field. After a tenant submits a registration request, the system extracts the relevant information through the form parsing module.

[0106] As an alternative implementation, tenants submit registration requests by uploading registration information documents. The system uses a document parsing tool to parse the documents and extract tenant type information, business scenario descriptions, and estimated resource requirements.

[0107] Step S22: Based on the preset resource quota benchmark table and combined with tenant type information, determine the basic quota coefficient. Among them, the basic quota coefficient of enterprise tenants is higher than that of individual tenants, and the basic quota coefficient of priority tenants is higher than that of ordinary tenants of the same type.

[0108] In this embodiment, the resource quota baseline table is a pre-set table containing reference values ​​for basic quota coefficients corresponding to different tenant types. The basic quota coefficient is used to adjust the baseline resource amount when calculating the initial resource quota; the larger the coefficient, the more resources are allocated.

[0109] As an optional implementation, the resource quota baseline table specifies that the basic quota coefficient for individual tenants is 1.0, for enterprise tenants it is 1.5, for priority individual tenants it is 1.2, and for priority enterprise tenants it is 1.8. The system directly matches the corresponding basic quota coefficient from the table based on the parsed tenant type information.

[0110] As another optional implementation, the system sets up a basic quota coefficient calculation model, inputs additional parameters such as tenant type information and tenant size, and the model calculates the basic quota coefficient through an algorithm. For example, enterprise tenants are divided into tiers according to the number of employees, and different tiers correspond to different coefficients.

[0111] Step S23: Match the corresponding resource weight matrix according to the business scenario description. In the computing-intensive scenario, the weight ratio of CPU and GPU is higher than that of memory and storage. In the storage-intensive scenario, the weight ratio of storage is higher than that of CPU, GPU and memory.

[0112] In this embodiment, the resource weight matrix is ​​a matrix composed of the weight values ​​of various resources (CPU, memory, GPU, storage), and the weight values ​​reflect the importance of the resource in the corresponding business scenario.

[0113] As an optional implementation, the system presets three resource weight matrices: a computationally intensive matrix of CPU:GPU:Memory:Storage = 4:3:2:1, a storage-intensive matrix of Storage:CPU:Memory:GPU = 4:2:2:2, and a network-intensive matrix of Memory:GPU:CPU:Storage = 3:3:2:2. The system directly matches the corresponding matrix based on the business scenario description.

[0114] As an alternative implementation, the system allows administrators to customize resource weight matrices. After a tenant selects a business scenario, the system associates the scenario with the custom matrix set by the administrator.

[0115] Step S24: Combine the basic quota coefficient, resource weight matrix and estimated resource demand to calculate the first resource allocation, the second resource allocation, the third resource allocation and the fourth resource allocation to determine the tenant's initial resource quota, where the first resource is CPU, the second resource is memory, the third resource is GPU and the fourth resource is storage.

[0116] In this embodiment, the first resource allocation is the initial allocation of CPU, the second resource allocation is the initial allocation of memory, the third resource allocation is the initial allocation of GPU, and the fourth resource allocation is the initial allocation of storage. The initial resource quota is the resource allocation limit for the tenant, which is the sum of these four resource allocations.

[0117] As an optional implementation, the system first determines the baseline quantity of each resource based on the estimated resource demand, and then multiplies the baseline quantity by the basic quota coefficient and the weight value of the corresponding resource in the weight matrix to obtain the allocation quantity of each resource. For example, if the estimated CPU demand is 10 cores, the basic quota coefficient is 1.5, and the weight is 0.4, then the CPU allocation quantity = 10 × 1.5 × 0.4 = 6 cores.

[0118] As another optional implementation method, the system sets the resource allocation calculation formula: resource allocation = (estimated resource demand × basic quota coefficient) × resource weight + scenario basic resource quantity, where the scenario basic resource quantity is the minimum guaranteed quantity of various resources under different business scenarios to ensure that tenants obtain basic resources.

[0119] Step S25: Associate the initial resource quota with the tenant identifier and store it, and set the resource upper limit threshold for the tenant. The resource upper limit threshold is a preset multiple of the initial resource quota and does not exceed a preset percentage of the total available resources of the cluster.

[0120] In this embodiment, the tenant identifier is a string or code used to uniquely identify the tenant. The resource limit threshold is a maximum limit set by the system for tenants, allowing them to use resources to prevent them from over-consuming resources.

[0121] As an optional implementation, the system associates the initial resource quota with the tenant ID and stores it in the tenant resource table of the database. The resource upper limit threshold is set to twice the initial resource quota, and does not exceed 10% of the total available resources in the cluster. Database constraints ensure the threshold setting is effective.

[0122] As an alternative implementation, the system uses a distributed storage system to store tenant resource information, and distributes the initial resource quota and tenant identifier for storage. The resource upper limit threshold is dynamically adjusted according to the cluster load, set to 2.5 times the initial quota when the load is low and 1.8 times when the load is high, and neither exceeds 8% of the total available resources of the cluster.

[0123] For example, a corporate tenant submits a registration request. The request is parsed to identify the tenant type as corporate, the business scenario as compute-intensive, and the estimated resource requirements as 20 CPU cores, 30GB memory, 5 GPUs, and 100GB storage. The system matches the corporate tenant's base quota coefficient of 1.5 from the resource quota baseline table. Based on the compute-intensive scenario, the matched resource weight matrix is ​​CPU:GPU:Memory:Storage = 4:3:2:1. The resource allocation is calculated as follows: CPU = 20 × 1.5 × (4 / 10) = 12 cores, Memory = 30 × 1.5 × (2 / 10) = 9GB, GPU = 5 × 1.5 × (3 / 10) = 2.25 GPUs, Storage = 100 × 1.5 × (1 / 10) = 15GB. The initial resource quota is associated with the corporate tenant's identifier and the resource upper limit threshold is set to twice the initial quota, and cannot exceed 10% of the total available resources in the cluster.

[0124] This embodiment receives tenant registration requests and parses key information, determines the basic quota coefficient based on the tenant type, matches the resource weight matrix according to the business scenario, and finally calculates the initial resource quota and sets the upper limit threshold. This makes the initial resource allocation more in line with the actual needs of tenants and the characteristics of business scenarios, ensuring the basic resource needs of tenants and preventing resource abuse through the upper limit threshold, thus laying a reasonable foundation for subsequent dynamic resource adjustments.

[0125] Based on any of the above embodiments, in Embodiment 4 of this application, step S30 includes:

[0126] Step S31: If the operation type is to deploy a new application, calculate the changes in resource requirements for CPU, memory, GPU and storage based on the parsed single-copy CPU request, memory request, GPU request, storage request and preset number of copies.

[0127] In this embodiment, the resource request amount required by a single replica refers to the amount of various resources requested by a single application replica during runtime. The preset number of replicas is the total number of application replicas that the tenant expects to deploy. The resource demand change amount is the amount of various resources required due to the deployment of new applications.

[0128] As an optional implementation, the system extracts the CPU, memory, GPU, and storage request volume of a single copy and the preset number of copies from the parsed operation content, and calculates them separately through multiplication operations. That is, the change in CPU resource demand = CPU request volume of a single copy × preset number of copies. The calculation method for the change in memory, GPU, and storage resource demand is similar.

[0129] As an alternative implementation, the system sets a resource redundancy coefficient, which is multiplied by the basic calculation result to cope with possible resource fluctuations. For example, if the redundancy coefficient is set to 1.2, then the change in CPU resource demand = single-replica CPU request quantity × preset number of replicas × 1.2. The calculation method is the same for other resource types.

[0130] Step S32: If the operation type is to perform a scaling up or down operation on an existing application, the resource requirement change for each resource type is calculated based on the difference between the current number of replicas and the target number of replicas obtained from parsing, combined with the fixed resource configuration information of a single replica.

[0131] In this embodiment, the current number of replicas is the number of running replicas of the application before the operation, the target number of replicas is the expected number of replicas after the operation, a positive difference indicates expansion, and a negative difference indicates reduction, and the baseline quantity is the fixed amount of various resources occupied by a single replica. The change in resource demand for each resource type is calculated using the formula "Change in resource demand = (Target number of replicas - Current number of replicas) × Baseline quantity".

[0132] As an optional implementation, the system directly substitutes the parsed current number of replicas, target number of replicas, and baseline resource quantities for each replica into the formula to calculate the changes in resource requirements for CPU, memory, GPU, and storage. If the target number of replicas is greater than the current number of replicas, the result is positive, meaning resources need to be increased; otherwise, it is negative, meaning resources need to be reduced.

[0133] As an alternative implementation, the system incorporates a step coefficient during calculation. When the number of replicas changes significantly, such as when the difference exceeds a preset threshold, the calculation results are adjusted in a stepwise manner. For example, the coefficient is 1 when the difference is within 5, and 0.9 when it exceeds 5, to avoid over-allocation or under-allocation of resources.

[0134] Step S33: If the operation type is to update the application image version, calculate the difference in resource requirement parameters between the new version image and the current image version, and use the difference as the resource requirement change for each resource type.

[0135] In this embodiment, the resource requirement parameters are the restrictions or requirements on various resources during image runtime, such as CPU limit, memory limit, etc. The difference is the difference between the new version and the current version in terms of resource requirement parameters. Positive numbers indicate an increase in resource requirements, and negative numbers indicate a decrease.

[0136] As an optional implementation, the system extracts parameters such as CPU limit, memory limit, GPU utilization threshold, and storage IOPS requirement of the current image and the new version image, and calculates the difference one by one. That is, the change in CPU resource requirement = CPU limit of the new version - CPU limit of the current version. The difference calculation method is the same for other resource types. These differences are the corresponding changes in resource requirements.

[0137] As another optional implementation, the system performs a reasonableness check on the calculated difference. If the absolute value of the difference for a certain type of resource exceeds the preset range (e.g., the CPU difference exceeds 50% of the current version's CPU limit), an early warning is issued and manual confirmation is requested. After confirmation, the difference is used as the change in resource demand.

[0138] Step S34: If the operation type is to adjust the application runtime resource request parameters, the parsed adjustment values ​​of each resource type request quantity are directly used as the corresponding resource demand change quantity.

[0139] In this embodiment, the resource type request quantity adjustment value is a specific numerical value that the tenant adjusts for the request quantity of various resources during application runtime. A positive number indicates an increase in the request quantity, and a negative number indicates a decrease in the request quantity. The change in resource demand is consistent with this adjustment value.

[0140] As an optional implementation, the system directly assigns the requested adjustment values ​​for resource types such as CPU, memory, GPU, and storage obtained from parsing to the corresponding resource demand changes without additional calculations.

[0141] As another optional implementation, the system limits the range of the adjustment value. If the adjustment value exceeds a certain percentage (e.g., 30%) of the initial quota for the resource type, it is truncated proportionally, and the truncated value is used as the change in resource demand, and the adjustment log is recorded.

[0142] For example, the tenant performed four operations: When deploying a new application, the single-replica CPU request is 2 cores, memory 3GB, GPU 0.5 card, and storage 10GB. The preset number of replicas is 4. The calculated change in CPU resource requirements is 2×4=8 cores, memory=3×4=12GB, GPU=0.5×4=2 cards, and storage=10×4=40GB. For scaling up or down existing application replicas, the current number of replicas is 2, the target number of replicas is 5, the base CPU requirement per replica is 1 core, and the change in CPU resource requirements is (5-2)×1=3 cores. For updating the application image version, the current version has a CPU limit of 4 cores, and the new version has a CPU limit of 6 cores, so the change in CPU resource requirements is 6-4=2 cores. For adjusting runtime resource parameters, the CPU request is adjusted to 1 core, so the change in CPU resource requirements is 1 core.

[0143] This embodiment ensures the accuracy of resource demand changes by developing precise calculation methods for different operation types, providing a reliable basis for subsequent resource allocation adjustments. This helps the container management system to more rationally schedule resources and meet the dynamic needs of tenants.

[0144] Based on any of the above embodiments, in Embodiment 5 of this application, the real-time resource allocation amount is obtained through the initial resource quota, the amount of resources used, the resource type weight, the change in resource demand, and the tenant priority factor.

[0145] Specifically, the resource allocation formula is: Real-time resource allocation amount = (Initial resource quota - Used resource amount) × Resource type weight + Resource demand change amount × Tenant priority factor.

[0146] In this embodiment, the amount of resources used is the amount of various resources currently actually occupied by the tenant; the initial resource quota is the initial quota of various resources allocated by the system when the tenant registers; the change in resource demand is the change in the tenant's demand for various resources caused by the triggered operation; the resource type weight is a weight value set according to the importance of different resources in the business scenario, and the sum of the weights of each resource type is 1; the tenant priority factor is a coefficient set according to the tenant level, used to reflect the priority difference of different tenants when allocating resources.

[0147] As an optional implementation, the system assigns resource type weights to CPU, memory, GPU, and storage, for example, 0.4 for CPU, 0.3 for GPU, 0.2 for memory, and 0.1 for storage. Simultaneously, priority factors are assigned to different tenants: 1.0 for individual tenants, 1.2 for enterprise tenants, and 1.5 for priority tenants. During calculation, the used resource amount, initial resource quota, and changes in resource demand corresponding to each resource type are substituted into the formula to obtain the real-time resource allocation for each type of resource.

[0148] As an alternative implementation, the system allows administrators to dynamically adjust resource type weights and tenant priority factors based on cluster resource usage. For example, when GPU resources are scarce in the cluster, the resource type weight of the GPU is reduced; when a certain type of tenant's business is urgent, its priority factor is temporarily increased. During calculation, the adjusted weights and factors are substituted into the formula for computation.

[0149] For example, in the initial resource allocation of a certain enterprise tenant (priority factor 1.2), the CPU has 10 cores, 4 cores are already used, and the CPU resource demand changes by 3 cores due to the deployment of a new application. The CPU resource type weight is 0.4. Substituting these data into the formula, the real-time CPU resource allocation is calculated as (10-4)×0.4+3×1.2=2.4+3.6=6 cores. Similarly, the real-time resource allocation for the tenant's memory, GPU, and storage can be calculated.

[0150] This embodiment introduces a resource allocation formula that incorporates resource type weights and tenant priority factors. This formula ensures that the calculation of real-time resource allocation considers both the importance of the resources themselves and the differences in tenant priorities. This makes resource allocation more reasonable and accurate, better adaptable to different business scenarios and tenant needs, and improves the flexibility and effectiveness of resource scheduling in the container management system.

[0151] Based on any of the above embodiments, in Embodiment Six of this application, after step S50, the following is included:

[0152] Step A10: For CPU, memory, GPU, and storage, calculate the ratio of used resources to initial resource quota to obtain the utilization rate of each resource type.

[0153] In this embodiment, the amount of resources used is the amount of various resources currently actually occupied by the tenant, the initial resource quota is the initial quota of various resources obtained by the tenant when registering, and the utilization rate is the percentage of the amount of resources used relative to the initial resource quota, which is used to reflect the saturation of various resources.

[0154] As an optional implementation, the system obtains the amount of used resources for CPU, memory, GPU, and storage from the resource monitoring module, extracts the corresponding initial resource quota from the tenant resource configuration table, and calculates them separately through division. That is, CPU utilization = (CPU used resources ÷ CPU initial resource quota) × 100%, and the utilization of memory, GPU, and storage is calculated in the same way.

[0155] As another optional implementation, the system sets a data collection cycle (e.g., every 5 minutes), collects the amount of resources used and the initial resource quota in each cycle, calculates the utilization rate of each resource type, and takes the average of multiple cycles as the final utilization rate to reduce the impact of data fluctuations.

[0156] Step A20: Based on the preset health assessment model, map the utilization rate of each resource type to the corresponding health value.

[0157] In this embodiment, the health assessment model is a pre-set rule model used to convert resource utilization rate into health score. The health score is a numerical value that reflects the health status of resource use, and the range can be set from 0 to 100 points. The higher the score, the better the health status.

[0158] As an optional implementation, the health assessment model is set as follows: a health score of 90-100 points when the usage rate is ≤60%; 70-89 points when the usage rate is ≤80% (60% < 80%); 50-69 points when the usage rate is ≤90% (80% < 90%); and 0-49 points when the usage rate is >90%. The system directly matches the corresponding health score range from the model based on the usage rate of each resource type, and then takes the median value as the health score for that resource type.

[0159] As another optional implementation method, the health assessment model adopts a linear mapping method, where 0% usage corresponds to 100 points, 100% usage corresponds to 0 points, and the intermediate usage rate is used to calculate the health value in a linear proportion, that is, health value = 100 - (usage rate × 100). For example, when the usage rate is 70%, the health value is 30 points.

[0160] Step A30: Determine the health weight of each resource type, with CPU and GPU having a higher weight than memory and storage.

[0161] In this embodiment, the health weight is a coefficient that reflects the importance of each resource type in the overall health assessment. The higher the weight, the greater the impact of the health status of that resource type on the overall health.

[0162] As an optional implementation, the system presets health weights as follows: CPU 0.35, GPU 0.3, memory 0.2, and storage 0.15, with the sum of each weight being 1, thereby reflecting that the importance of CPU and GPU is higher than that of memory and storage.

[0163] As another optional implementation, the system allows the weights to be adjusted according to the business scenario. In compute-intensive scenarios, the weight of GPU is increased to 0.35 and the weight of CPU is increased to 0.35. In storage-intensive scenarios, the weight of storage is increased to 0.25, while ensuring that the weights of CPU and GPU are always higher than those of memory and storage.

[0164] Step A40: Calculate the overall health of the tenant using the health values ​​of each resource type and the configured health weights.

[0165] Specifically, the overall health of a tenant is calculated by using the formula: Overall Health = Σ (Health Value × Configured Health Weight).

[0166] In this embodiment, the overall health score is a comprehensive health score of tenant resource usage obtained by considering the health status of various resources, which is used to intuitively reflect the overall health level of tenant resource usage.

[0167] As an optional implementation, the system multiplies the health value of each resource type by its corresponding health weight, and then adds the products together. That is, the overall health value = CPU health value × CPU weight + memory health value × memory weight + GPU health value × GPU weight + storage health value × storage weight, and the final result is obtained and rounded to one decimal place.

[0168] As another optional implementation, the system normalizes the calculation results, limiting the overall health score to the range of 0-100 points. If the calculation result exceeds 100 points, it is taken as 100 points; if it is below 0 points, it is taken as 0 points, thus ensuring the rationality of the scoring.

[0169] For example, a tenant's CPU usage is 6 cores (initial quota 10 cores, utilization 60%), with a mapped health score of 90; memory usage is 12GB (initial quota 20GB, utilization 60%), with a health score of 90; GPU usage is 3 cards (initial quota 5 cards, utilization 60%), with a health score of 90; storage usage is 80GB (initial quota 100GB, utilization 80%), with a health score of 80. The health score weights are set as follows: CPU 0.35, GPU 0.3, memory 0.2, storage 0.15. The overall health score is calculated as follows: 90 × 0.35 + 90 × 0.2 + 90 × 0.3 + 80 × 0.15 = 31.5 + 18 + 27 + 12 = 88.5 points.

[0170] This embodiment calculates the utilization rate, health value, and overall health of each resource type step by step, and distinguishes the importance of resources by weight. It can comprehensively reflect the health status of tenant resource usage, provide a basis for subsequent resource adjustments in the system, help to discover resource usage risks in advance, and ensure the stable operation of tenant services.

[0171] Based on any of the above embodiments, in Embodiment Seven of this application, referring to Figure 2 After step S50, the following is included:

[0172] Step S61: Determine the initial GPU resource limits for computing GPUs, rendering GPUs, and general-purpose GPUs based on the initial resource quotas corresponding to the GPUs.

[0173] In this embodiment, the GPU portion of the initial resource quota is the initial total amount of GPU resources obtained when the tenant registers; compute GPUs are GPU types suitable for high-performance computing scenarios, rendering GPUs are GPU types suitable for graphics rendering scenarios, and general-purpose GPUs are GPU types that take into account multiple scenarios; the initial GPU resource limit is the initial usage limit set separately for different types of GPUs.

[0174] As an optional implementation, the system extracts the total GPU quota from the initial resource quota and allocates it according to the business scenario selected by the tenant during registration. For example, in a compute-intensive scenario, compute-intensive GPUs account for 60%, general-purpose GPUs account for 30%, and rendering GPUs account for 10%, thereby determining the initial resource limits for each type of GPU.

[0175] As another optional implementation method, the system presets the basic allocation ratio of various types of GPUs, computing type: rendering type: general type = 5:2:3. Then, combined with the initial total quota of GPUs, the initial resource limit of each type of GPU is calculated, that is, the initial limit of a certain type = total quota × corresponding ratio.

[0176] Step S62: Obtain the tenant's initial GPU resource limit usage.

[0177] The initial GPU resource limit utilization rate is calculated as follows: (Current GPU usage ÷ Initial GPU resource limit) × 100%.

[0178] In this embodiment, the current GPU usage is the total amount of various GPU resources currently actually occupied by the tenant; the initial GPU resource limit is the sum of various GPU resource limits determined in step S61; and the initial GPU resource limit utilization rate is an indicator reflecting the proportion of current GPU resource usage to the initial limit.

[0179] As an optional implementation, the system collects the amount of computing, rendering, and general-purpose GPU resources currently used by the tenant in real time, sums them to obtain the current GPU usage, substitutes them into the formula to calculate the utilization rate, and the result is rounded to two decimal places.

[0180] As another optional implementation, the system calculates the utilization rate according to GPU type, and then takes the average value as the initial GPU resource limit utilization rate. For example, if the utilization rate of computing type is 80%, rendering type is 60%, and general type is 70%, then the average utilization rate is 70%.

[0181] Step S63: Extract the daily peak utilization rate, average utilization rate and resource request frequency corresponding to the tenant's historical GPU resource consumption data, and collect the current GPU resource usage and request queue length.

[0182] In this embodiment, historical GPU resource consumption data is a record of the GPU resources used by the tenant over a period of time; daily peak utilization rate is the highest percentage of GPU usage per day in the historical data; average utilization rate is the average percentage of GPU usage in the historical data; resource request frequency is the number of times the tenant requests GPU resources per unit time; current GPU resource usage is the amount of GPU resources currently actually occupied; and request queue length is the number of GPU resource requests waiting to be allocated.

[0183] As an optional implementation, the system extracts historical GPU data from the database for the past 30 days, calculates the daily peak and average utilization rates, counts the number of resource requests per hour as the request frequency, and obtains the current usage and request queue length through the resource monitoring module.

[0184] As another optional implementation, the system processes data separately according to GPU type, such as extracting the historical peak utilization of computing GPUs and the average utilization of rendering GPUs, and then integrating various types of data for subsequent calculations.

[0185] Step S64: Generate a dynamic correction factor based on daily peak utilization, average utilization, resource request frequency, current GPU resource usage, and request queue length.

[0186] In this embodiment, the dynamic correction factor is a coefficient calculated based on various GPU resource usage indicators, used to dynamically adjust GPU resource limits so that resource allocation is more in line with actual needs.

[0187] As an optional implementation, the system assigns weights to each indicator: peak utilization rate accounts for 30%, average utilization rate accounts for 25%, request frequency accounts for 20%, current usage accounts for 15%, and request queue length accounts for 10%. After standardizing each indicator, the weighted sum is calculated and then mapped to a dynamic correction factor in the range of 0.8-1.5. For example, a comprehensive score of 0.6 corresponds to a factor of 1.2.

[0188] As another optional implementation, the system sets a threshold judgment rule: when the average utilization rate is ≤50% and the request queue length is 0, the factor is 0.9; when the average utilization rate is 50%-80% and the queue length is ≤2, the factor is 1.1; when the average utilization rate is >80% or the queue length is >2, the factor is 1.3.

[0189] Step S65: Adjust the tenant's GPU resource limits according to the dynamic correction factor.

[0190] For example, the adjustment formula is: Corrected GPU resource limit = Initial GPU resource limit × Dynamic correction factor, wherein the corrected GPU resource limit does not exceed the GPU resource limit set by the cluster for the tenant, nor is it lower than the tenant's current GPU resource usage.

[0191] In this embodiment, the corrected GPU resource limit is the adjusted limit of GPU resources that a tenant can use; the upper limit of GPU resources set by the cluster for a tenant is the maximum limit set by the system to prevent a tenant from over-consuming GPU resources; and the current GPU resource usage is the amount of GPU resources actually used by the tenant at the time of adjustment.

[0192] As an optional implementation, the system multiplies the initial GPU resource limit by a dynamic correction factor to obtain a corrected value. If the value exceeds the upper limit, the upper limit value is used; if it is lower than the current usage, the current usage is used, ensuring that the adjustment is reasonable.

[0193] As another optional implementation, the system calculates the corrected GPU resource limit according to GPU type, such as computing GPU = initial computing limit × dynamic correction factor, and then sums up all kinds of limits to obtain the total corrected limit, while ensuring that all kinds of limits meet the upper and lower limit requirements.

[0194] For example, a tenant's initial GPU resource quota is 10 cards, with initial limits set at 5 cards for compute, 2 cards for rendering, and 3 cards for general-purpose use, based on a ratio of 5:2:3. The current GPU usage is 6 cards, resulting in an initial limit utilization rate of (6 ÷ 10) × 100% = 60%. Historical data from the past 30 days is extracted: daily peak utilization rate 75%, average utilization rate 60%, request frequency 3 times per hour, current usage of 6 cards, and request queue length 1. A dynamic correction factor of 1.1 is generated according to threshold rules. The corrected GPU resource limit is 10 × 1.1 = 11 cards. This value does not exceed the cluster's set limit of 15 cards and is higher than the current usage of 6 cards; therefore, the final corrected limit is determined to be 11 cards.

[0195] This embodiment achieves precise adjustment of GPU resource limits by subdividing GPU types and combining historical and real-time data to generate dynamic correction factors. This not only meets the actual usage needs of tenants but also avoids resource waste, thereby improving the utilization efficiency and scheduling flexibility of GPU resources.

[0196] Based on any of the above embodiments, in Embodiment Eight of this application, referring to Figure 3 Before the steps of resolving the operation type and operation content of the trigger operation in response to a dynamic resource demand, the procedure includes:

[0197] Step B10: In response to the virtual cluster isolation command, determine the virtual cluster instance of the tenant from which the virtual cluster isolation command originates. The virtual cluster instance includes a virtual API server, a virtual controller manager, and a virtual scheduler. The virtual cluster instance and the physical cluster achieve isolated scheduling of container resources through a resource mapping layer.

[0198] In this embodiment, the virtual cluster isolation command is used to start or configure the virtual cluster isolation mechanism; the virtual cluster instance is a virtual cluster unit created separately for a tenant, containing core virtual components that implement cluster functions; the virtual API server is a component that processes API requests within the virtual cluster; the virtual controller manager is a component that manages controllers within the virtual cluster; the virtual scheduler is a component responsible for resource scheduling within the virtual cluster; and the resource mapping layer is an intermediate layer that connects the virtual cluster and the physical cluster, realizing resource mapping and isolation scheduling.

[0199] As an optional implementation, after receiving the virtual cluster isolation command, the system parses the tenant identifier carried in the command and searches for the corresponding virtual cluster instance from the cluster instance list based on the tenant identifier. This instance includes a preset virtual API server, virtual controller manager, and virtual scheduler, and establishes an isolation scheduling relationship with the physical cluster through the resource mapping layer.

[0200] As another optional implementation, after receiving the isolation command, the system first verifies the legality of the command, confirms the reliability of the source through command signature verification, and then locates the virtual cluster instance based on the tenant information in the command, checks whether the virtual components in the instance are running normally, and ensures that the resource mapping layer is in an active state.

[0201] Step B20 deploys the virtual control plane component in a dedicated namespace of the underlying physical Kubernetes cluster.

[0202] In this embodiment, the virtual control plane component is a collection of components responsible for control and management functions in the virtual cluster instance, including the virtual API server, virtual controller manager, and virtual scheduler; the underlying physical Kubernetes cluster is the physical cluster that actually runs the containers; the dedicated namespace is an isolated space specifically allocated for the virtual control plane component in the physical cluster to limit the scope of the component's operation.

[0203] As an optional implementation, the system uses a cluster deployment tool to point the deployment configuration file of the virtual control plane component to a pre-created dedicated namespace in the physical Kubernetes cluster. The configuration file contains information such as the component's image address and resource limits, and the deployment tool automatically completes the component deployment based on the configuration file.

[0204] As another optional implementation, the system adopts a dynamic namespace creation mechanism. After receiving the deployment instruction, it automatically creates a dedicated namespace in the physical cluster with the tenant identifier as the suffix, then deploys the virtual control plane component to the namespace, and configures the access permission policy of the namespace.

[0205] The steps of resolving the operation type and operation content of the trigger operation in response to a dynamic resource demand include:

[0206] Step B30: In response to a tap operation of the virtual control plane component, determine the API interface;

[0207] Step B40: If the API interface belongs to the virtual cluster instance associated with the tenant's tenant identifier, execute the step of parsing the operation type and operation content of the triggering operation.

[0208] In this embodiment, the tap operation is an operation request initiated by the virtual control plane component; the API interface is an application programming interface used for interaction between different components or systems; the tenant identifier is identification information used to uniquely identify the tenant.

[0209] As an optional implementation, after the system detects a tap operation on the virtual control plane component, it captures the API interface call information corresponding to the operation, extracts the identification information of the API interface, compares it with the list of API interfaces contained in the virtual cluster instance associated with the tenant identifier, and if they match, it performs the parsing step.

[0210] As an alternative implementation, the system sets a unique access token for the API interface of each virtual cluster instance. When a tap operation is detected, the system verifies the token carried in the request. If the token matches the virtual cluster instance associated with the tenant identifier, the system confirms that the API interface belongs to that instance and then performs the parsing step.

[0211] For example, when a tenant triggers a virtual cluster isolation command, the system responds by identifying the tenant's virtual cluster instance. This instance includes a virtual API server, a virtual controller manager, and a virtual scheduler, and is isolated from the physical cluster scheduling through a resource mapping layer. The system deploys these virtual control plane components to the "tenant-123-vcluster" dedicated namespace of the underlying physical Kubernetes cluster. When the tenant performs a click operation through the virtual controller manager, the system identifies the corresponding API interface, checks and finds that the API interface belongs to the virtual cluster instance associated with the tenant identifier "123," and then executes the step of parsing the operation type and content of the triggered operation.

[0212] This embodiment achieves tenant isolation based on virtual clusters by determining virtual cluster instances, deploying virtual control plane components to dedicated namespaces, and verifying API interface ownership. This ensures that tenant operations are only valid within their own virtual cluster instances, enhancing the security and isolation of the container management system, while also guaranteeing the accuracy and relevance of dynamic resource demand-triggered operation parsing.

[0213] This application provides a control device for a container management system, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the control method of the container management system in Embodiment 1 described above.

[0214] The following is for reference. Figure 4 The diagram illustrates a hardware architecture schematic suitable for implementing the container management system of the embodiments of this application. The control device for the container management system in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablets, and in-vehicle terminals, as well as fixed terminals such as digital TVs and desktop computers. Figure 4 The control device of the container management system shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0215] like Figure 4 As shown, the control device of the container management system may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the control device of the container management system. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the container management system's control device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a container management system control device with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0216] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0217] The control device for the container management system provided in this application, employing the control method of the container management system in the above embodiments, can solve the technical problem that in scenarios with dynamic business needs of tenants, some tenants may excessively consume resources, leading to restrictions on the operation of other tenant applications. Compared with the prior art, the beneficial effects of the control device for the container management system provided in this application are the same as those of the control device for the container management system provided in the above embodiments, and other technical features in the control device for the container management system are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0218] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0220] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the control method of the container management system in the above embodiments.

[0221] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), or any suitable combination thereof.

[0222] The aforementioned computer-readable storage medium may be included in the control device of the container management system; or it may exist independently and not be assembled into the control device of the container management system.

[0223] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the control device of the container management system, the control device of the container management system causes the following to occur: In response to a triggering operation for dynamic resource demand, the control device parses the operation type and operation content of the triggering operation, wherein the operation type includes deploying a new application, performing scaling operations on an existing application, updating the application image version, and adjusting application runtime resource request parameters; obtains the initial resource quota allocated to the tenant during registration corresponding to the triggering operation, wherein the initial resource quota includes a first resource allocation amount, a second resource allocation amount, a third resource allocation amount, and a fourth resource allocation amount; determines the change in resource demand corresponding to the triggering operation based on the operation type and the operation content; substitutes the used resource amount, the initial resource quota, and the change in resource demand into a preset resource allocation formula to calculate the tenant's real-time resource allocation amount; adjusts the tenant's resource usage quota based on the real-time resource allocation amount and synchronously updates the resource scheduling strategy of the cluster nodes.

[0224] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0225] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0226] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0227] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the control method of the container management system described above. This addresses the technical problem that, in scenarios with dynamic business needs of tenants, some tenants may excessively consume resources, leading to restrictions on the operation of other tenant applications. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the control method of the container management system provided in the above embodiments, and will not be elaborated upon here.

[0228] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the control method for the container management system described above.

[0229] The computer program product provided in this application can solve the technical problem that in scenarios with dynamic business needs of tenants, some tenants may excessively consume resources, leading to restrictions on the operation of other tenant applications. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the control method of the container management system provided in the above embodiments, and will not be repeated here.

[0230] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

Claims

1. A control method of a container management system, characterized by, The first resource is CPU, the second resource is memory, the third resource is GPU, and the fourth resource is storage. The control method of the container management system comprises: In response to a trigger operation of dynamic resource demand, the operation type of the trigger operation and the operation content of the trigger operation are analyzed. The operation type includes deploying a new application, performing a scaling operation on an existing application, updating an application image version, and adjusting an application runtime resource request parameter; A registration request of a tenant is received, and tenant type information, business scenario description, and estimated resource demand are obtained by analyzing the registration request. The tenant type information includes individual tenants, enterprise tenants, or priority tenants. The business scenario description includes compute-intensive, storage-intensive, or network-intensive. Based on the preset resource quota benchmark table, the basic quota coefficient is determined based on the tenant type information. The basic quota coefficient of the enterprise tenant is higher than that of the individual tenant, and the basic quota coefficient of the priority tenant is higher than that of the ordinary tenant of the same type. According to the business scenario description, a corresponding resource weight matrix is matched. In the compute-intensive scenario, the weight proportion of CPU and GPU is higher than that of memory and storage. In the storage-intensive scenario, the weight proportion of storage is higher than that of CPU, GPU, and memory. The first resource allocation, the second resource allocation, the third resource allocation, and the fourth resource allocation are calculated based on the basic quota coefficient, the resource weight matrix, and the estimated resource demand to determine the initial resource quota of the tenant. The initial resource quota is associated with the tenant identifier and stored, and the resource upper limit threshold of the tenant is set. The resource upper limit threshold is a preset multiple of the initial resource quota and does not exceed a preset proportion of the total available resources of the cluster. The initial resource quota allocated when the tenant registers is obtained. The initial resource quota includes the first resource allocation, the second resource allocation, the third resource allocation, and the fourth resource allocation. According to the operation type and the operation content, the resource demand change corresponding to the trigger operation is determined. The real-time resource allocation of the tenant is calculated by substituting the used resource amount, the initial resource quota, and the resource demand change into the preset resource allocation formula. The resource usage quota of the tenant is adjusted according to the real-time resource allocation, and the resource scheduling strategy of the cluster node is updated synchronously. According to the initial resource quota of the GPU, the initial GPU resource limit corresponding to the compute-type GPU, the rendering-type GPU, and the general-purpose GPU is determined. The initial GPU resource limit usage rate of the tenant is obtained. The daily peak usage rate, the average usage rate, and the resource request frequency corresponding to the historical GPU resource consumption data of the tenant are extracted, and the current GPU resource usage and the request queue length are collected. A dynamic correction factor is generated based on the daily peak usage rate, the average usage rate, the resource request frequency, the current GPU resource usage, and the request queue length. The GPU resource limit of the tenant is adjusted according to the dynamic correction factor.

2. The control method of the container management system according to claim 1, characterized by, The step of responding to the trigger operation of dynamic resource demand, analyzing the operation type of the trigger operation and the operation content of the trigger operation, comprises: If the operation type is to deploy a new application, the operation content is parsed to obtain a preset number of replicas, a CPU request amount required for a single replica, a memory request amount, a GPU request amount, and a storage request amount; If the operation type is to perform an operation of expanding or shrinking replicas on an existing application, the operation content is parsed to obtain a current number of replicas, a target number of replicas, and resource fixed configuration information of a single replica, wherein the resource fixed configuration information includes a benchmark amount of CPU, memory, GPU, and storage occupied by a single replica; If the operation type is to update an application image version, the operation content is parsed to obtain resource requirement parameters of a current image version and resource requirement parameters of a new version image, and the resource requirement parameters include a CPU upper limit, a memory upper limit, a GPU usage threshold, and a storage IOPS requirement; If the operation type is to adjust a runtime resource request parameter of an application, the operation content is parsed to obtain a resource type to be adjusted and a corresponding request amount adjustment value, wherein the resource type includes at least one of CPU, memory, GPU, and storage.

3. The control method of the container management system according to claim 1, characterized by, The step of determining the resource requirement change amount corresponding to the trigger operation according to the operation type and the operation content includes: If the operation type is to deploy a new application, the resource requirement change amounts of CPU, memory, GPU, and storage are respectively calculated based on the parsed CPU request amount required for a single replica, the memory request amount, the GPU request amount, the storage request amount, and the preset number of replicas; If the operation type is to perform an operation of expanding or shrinking replicas on an existing application, the resource requirement change amounts of various resource types are calculated according to a difference between the parsed current number of replicas and the target number of replicas, in combination with the resource fixed configuration information of a single replica; If the operation type is to update an application image version, a difference between resource requirement parameters of a new version image and a current image version is calculated, and the difference is taken as the resource requirement change amount of each resource type; If the operation type is to adjust a runtime resource request parameter of an application, the parsed request amount adjustment value of each resource type is directly taken as the corresponding resource requirement change amount.

4. The control method of the container management system according to claim 1, characterized by, The real-time resource allocation amount is obtained through an initial resource quota, an amount of used resources, a resource type weight, a resource requirement change amount, and a tenant priority factor.

5. The control method of the container management system according to claim 1, wherein After the step of adjusting the resource usage quota of the tenant according to the real-time resource allocation amount and synchronously updating a resource scheduling strategy of a cluster node, the following steps are included: For CPU, memory, GPU, and storage, the proportion of the amount of used resources to the initial resource quota is calculated to obtain the usage rate of each resource type; Based on a preset health degree evaluation model, the usage rate of each resource type is mapped to a corresponding health degree value; The health degree weight of each resource type is determined, wherein the weight of CPU and GPU is higher than that of memory and storage; The overall health degree of the tenant is calculated through the health degree value of each resource type and the configured health degree weight.

6. The control method of the container management system according to claim 1, wherein Before the step of parsing the operation type of the trigger operation and the operation content of the trigger operation in response to the trigger operation of dynamic resource requirement, the following steps are included: In response to the virtual cluster isolation instruction, a virtual cluster instance of a source tenant of the virtual cluster isolation instruction is determined, the virtual cluster instance including a virtual API server, a virtual controller manager, and a virtual scheduler, and the virtual cluster instance and a physical cluster are connected through a resource mapping layer to realize isolated scheduling of container resources; deploying the virtual control plane component in a dedicated namespace of an underlying physical Kubernetes cluster; The step of analyzing the operation type of the trigger operation and the operation content of the trigger operation in response to the trigger operation triggered by the dynamic resource requirement comprises: In response to a point operation of the virtual control plane component, an API interface is determined; If the API interface belongs to a virtual cluster instance of the tenant associated with the tenant identifier, the step of analyzing the operation type of the trigger operation and the operation content of the trigger operation is performed.

7. A control device of a container management system, characterized by comprising: The control device of the container management system comprises a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the control method of the container management system according to any one of claims 1 to 6.

8. A storage medium, characterized by The storage medium is a computer readable storage medium, and the computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the control method of the container management system according to any one of claims 1 to 6.

Images