Container deployment method and system

Abstract

This application provides a container deployment method and system. The method includes: receiving a container deployment request, the container deployment request including multiple target business types corresponding to containers to be deployed; obtaining the resource utilization of multiple server nodes and the historical call frequency of a first container already deployed on the server nodes corresponding to the target business type; obtaining the target priority of each server node based on the resource utilization of each server node; obtaining the target call level of the first container based on the historical call frequency of the first container corresponding to the target business type; obtaining the target container level of the container to be deployed corresponding to the target business type based on the target business type; and determining the target server node corresponding to the container to be deployed corresponding to the target business type based on the target call level of the first container, the target container level of the container to be deployed, and the target priorities of the multiple server nodes, so as to create the container to be deployed on the target server node.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a container deployment method and system. Background Technology

[0002] With the rapid development of cloud computing and container technologies and the accelerated advancement of enterprise digital transformation, containerized deployment has become a core means of building resilient and scalable applications in modern information technology (IT) architectures. Major enterprises are actively promoting technology architecture upgrades, committed to adopting a unified container platform to support the diverse needs of different business units within the enterprise (such as core transactions, data analytics, log processing, etc.), thereby achieving rapid deployment of business applications on cluster resources and consistent service experience.

[0003] In this context, when enterprise IT departments develop and deploy shared container cloud service platforms for multiple users (such as business units and project teams), they often need to perform fixed deployments for a large number of containers that carry critical business operations. This is because these containers often need to mount dedicated data volumes (containing core configurations and historical data) and build fixed microservice dependency links, which means that once deployed, they cannot release the server resources they occupy by simply deleting or migrating them.

[0004] Resource scheduling strategies in container cloud environments play a crucial role in improving system performance, ensuring service quality, and increasing resource utilization. However, this fixed deployment leads to insufficient cluster capacity and imbalanced allocation, resulting in low efficiency. Summary of the Invention

[0005] This application provides a container deployment method and system to solve the problems of insufficient cluster operating capacity and imbalanced allocation caused by fixed deployment.

[0006] In a first aspect, embodiments of this application provide a container deployment method, including:

[0007] The system receives container deployment requests, which include multiple target business types corresponding to containers to be deployed; it obtains the resource utilization of multiple server nodes and the historical call frequency of the first container already deployed on the server nodes corresponding to the target business type; based on the resource utilization of each server node, it obtains the target priority of each server node; based on the historical call frequency of the first container corresponding to the target business type, it obtains the target call level of the first container; based on the target business type, it obtains the target container level of the container to be deployed corresponding to the target business type; and based on the target call level of the first container corresponding to the target business type, the target container level of the container to be deployed corresponding to the target business type, and the target priorities of multiple server nodes, it determines the target server node corresponding to the container to be deployed corresponding to the target business type, so as to create the container to be deployed on the target server node.

[0008] In one implementation of the first aspect, determining the target server node corresponding to the container to be deployed, based on the target call level of the first container corresponding to the target business type, the target container level of the container to be deployed corresponding to the target business type, and the target priorities of multiple server nodes, includes: obtaining multiple candidate server nodes corresponding to the container to be deployed based on a preset mapping relationship, the target call level of the first container corresponding to the target business type, the target container level of the container to be deployed corresponding to the target business type, and the target priorities of multiple server nodes; and determining the target server node corresponding to the container to be deployed from the multiple candidate server nodes; wherein, the preset mapping relationship is a pre-set relationship between the call level, container level, and server node priority.

[0009] In one implementation of the first aspect, determining the target server node corresponding to the container to be deployed from multiple candidate server nodes includes: determining the target server node corresponding to the container to be deployed from multiple candidate server nodes according to a preset container deployment rule; wherein the preset container deployment rule includes that the ratio of the number of containers of the same business type on any server node to the total number of containers on the server node is less than or equal to a preset occupancy threshold.

[0010] In one implementation of the first aspect, the target call level of the first container is obtained based on the historical call frequency of the first container corresponding to the target business type, including: determining the target call frequency range in which the historical call level is located based on the historical call frequency of the first container deployed on the server node corresponding to the target business type; and determining the target call level corresponding to the target call frequency range according to the preset correspondence between call levels and call frequency ranges.

[0011] In one implementation of the first aspect, obtaining the resource utilization rate of multiple server nodes and the historical call frequency of the first container deployed on the server nodes corresponding to the target business type includes: obtaining the first resources of multiple server nodes and the second resources of multiple containers to be deployed in the container deployment request; determining the sum of multiple first resources based on the multiple first resources and the multiple second resources; and obtaining the resource utilization rate of multiple server nodes and the historical call frequency of the first container deployed on the server nodes corresponding to the target business type when the sum of multiple first resources is greater than or equal to the sum of multiple second resources.

[0012] In one implementation of the first aspect, when the sum of multiple first resources is less than the sum of multiple second resources, the method further includes: obtaining multiple candidate first containers from the first containers of multiple server nodes, wherein the business type is non-real-time business, the container level is a preset container level, and the container idle time is greater than or equal to a first preset time; determining multiple target first containers from the multiple candidate first containers based on the second resources of the multiple containers to be deployed and the third resources of the multiple candidate first containers, and shutting down the multiple target first containers.

[0013] In one implementation of the first aspect, determining multiple target first containers from multiple candidate first containers based on the second resources of multiple containers to be deployed and the third resources of multiple candidate first containers includes: calculating the third resources of multiple candidate first containers using a target algorithm to obtain multiple target first containers from multiple candidate first containers that meet the resource requirements of the second resources of multiple containers to be deployed, wherein the target algorithm is an algorithm combining a greedy algorithm and a dynamic programming algorithm.

[0014] In one implementation of the first aspect, closing multiple target first containers includes: sending container closure requests to the multiple target first containers respectively; and closing the target first containers if a first feedback message is received from a target first container.

[0015] In one implementation of the first aspect, after sending container shutdown requests to multiple target first containers respectively, the method further includes: if a second feedback message is received from a target first container, then at a second preset time interval, repeatedly sending the container shutdown request until a preset number of times is reached or a first feedback message is received, and then stopping sending the container shutdown request.

[0016] Secondly, embodiments of this application also provide a container deployment system, including:

[0017] The system comprises the following modules: a request receiving module for receiving container deployment requests, which include multiple target business types corresponding to containers to be deployed; a first acquisition module for acquiring the resource utilization rates of multiple server nodes and the historical call frequencies of the first container already deployed on the server nodes corresponding to the target business type; a second acquisition module for obtaining the target priority of each server node based on its resource utilization rate; a third acquisition module for obtaining the target call level of the first container based on its historical call frequency; a fourth acquisition module for obtaining the target container level of the container to be deployed corresponding to the target business type; and a deployment module for determining the target server node corresponding to the container to be deployed based on the target call level of the first container corresponding to the target business type, the target container level of the container to be deployed corresponding to the target business type, and the target priorities of the multiple server nodes, so as to create the container to be deployed on the target server node.

[0018] The technical solution of this application embodiment, upon receiving a container deployment request, first identifies the service type for which the container to be deployed serves, i.e., identifies the target service type. It collects the resource utilization rates of multiple server nodes and the historical call frequency of a first container belonging to the target service type. Based on the resource utilization rate of each server node, it obtains the target priority of each server node. Based on the historical call frequency of the first container corresponding to the target service type, it obtains the target call level of the first container. Based on the target service type, it obtains the target container level of the container to be deployed corresponding to the target service type. Based on the target priority, target call level, and target container level, it obtains the target server node corresponding to the container to be deployed corresponding to the target service type. Then, it creates the container to be deployed on the target server node, realizing the deployment of the container to be deployed in response to the container deployment request. The technical solution of this application embodiment comprehensively optimizes from multiple dimensions to determine the optimal deployment scheme. Through this dynamic and intelligent scheduling, the container is not fixed on the initially deployed server node. The new deployment will flexibly select the best location based on the current resource status of the server node and the historical behavior of the service, thereby fundamentally solving the problems of resource allocation imbalance and insufficient capacity utilization. Attached Figure Description

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

[0020] Figure 1 This is a flowchart illustrating a container deployment method in one embodiment of this application;

[0021] Figure 2 This is a flowchart illustrating another container deployment method in one embodiment of this application;

[0022] Figure 3 This is a flowchart illustrating another container deployment method in one embodiment of this application;

[0023] Figure 4 This is a schematic diagram of the structure of a container deployment system according to one embodiment of this application. Detailed Implementation

[0024] The embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described below do not represent all embodiments consistent with this application. They are merely examples of systems and methods consistent with some aspects of this application as detailed in the claims.

[0025] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0026] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms can be used interchangeably where appropriate.

[0027] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0028] In the embodiments of this application, the words "exemplary," "for example," or "for instance" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the words "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a specific manner.

[0029] To facilitate understanding, the technical terms used in this application will be introduced below.

[0030] Container cluster: A container cluster is a logical whole consisting of multiple servers (server nodes) connected by a high-speed network. These server nodes are managed in a unified manner, forming a resource pool of computing resources.

[0031] A server node is an independent, physical or virtual server (computing unit) in a container cluster. It is the operating system environment in which the container actually runs. Each server node has its own central processing unit (CPU), memory, disk and network resources.

[0032] Container: The carrier of an application and its dependencies, including lightweight, executable standalone packages containing the code, runtime environment, system tools, system libraries, and settings required to run an application.

[0033] The application scenarios of the embodiments of this application will be described by way of example below:

[0034] Resource scheduling strategies in container cloud environments play a crucial role in improving system performance, ensuring service quality, and increasing resource utilization, especially in typical scenarios such as multidimensional resource constraints (e.g., heterogeneous demands for resources such as CPUs, memory, GPUs, and storage with input / output operations per second), dynamic load fluctuations (e.g., sudden surges in traffic leading to increased resource demands), and multi-user isolation (preventing resource interference between different users or services).

[0035] However, in scenarios where multiple users jointly deploy containers, because containers mount dedicated data volumes and build fixed microservice dependency links, these containers often cannot release resources by deleting or migrating, resulting in insufficient container cluster operating capacity and unbalanced allocation, thus causing low usage efficiency.

[0036] To address the aforementioned technical problems, this application provides a container deployment method. The method involves receiving a container deployment request and obtaining the target business types corresponding to multiple containers to be deployed in the request. It also involves acquiring the resource utilization rates of multiple server nodes and the historical call frequencies of a first container deployed on a server node corresponding to the target business type. Based on the resource utilization rates of each server node, the target priority of each server node is obtained. Based on the historical call frequencies of the first container corresponding to the target business type, the target call level of the first container is obtained. Based on the target business type, the target container level of the container to be deployed corresponding to the target business type is obtained. Finally, based on the target call level of the first container corresponding to the target business type, the target container level of the container to be deployed corresponding to the target business type, and the target priorities of the multiple server nodes, the target server node corresponding to the container to be deployed corresponding to the target business type is determined. The container to be deployed is then created on the target server node, thereby resolving the problems of unbalanced resource allocation and insufficient operating capacity in container clusters caused by fixed container deployment.

[0037] In some embodiments, a container deployment method is provided, which can be applied to a container deployment system. For example, the container deployment system can be implemented in software and / or hardware.

[0038] Figure 1 This is a flowchart illustrating a container deployment method provided in an embodiment of this application, as shown below. Figure 1 As shown, the container deployment method of this application specifically includes the following steps:

[0039] Step S101: Receive container deployment request.

[0040] The container deployment request includes multiple target business types corresponding to the containers to be deployed. The request includes, but is not limited to, the number of containers to be deployed, the resources required for each container (such as CPU configuration parameters, memory capacity, etc.), and the business type identifier for each container. The business type identifier uniquely identifies a business type; optionally, it can be a business type label. CPU configuration parameters include, but are not limited to, the number of cores. Business types include, but are not limited to, payment transactions, log analysis, resource requirements, order queries, and user authentication.

[0041] For example, a container deployment request may include at least one sub-container deployment request from a user. The sub-container deployment request includes at least one container to be deployed required by the user, the business type of the container to be deployed, the number of containers to be deployed, etc. In this embodiment, the user can refer to a team, department, or project group whose businesses are independent and whose resources need to be isolated, such as a research and development group or a testing group. For example, in a single sub-container deployment request issued by a user, the business types of all containers to be deployed are the same.

[0042] For example, a container deployment request may include multiple containers to be deployed. The business types of each container to be deployed may be the same or different. This application does not impose any specific limitations on this.

[0043] For example, the same container to be deployed can be deployed as an image to multiple physical or virtual server nodes, and the number of server nodes deployed for images of different container levels can be set differently. For instance, the higher the container level, the higher the number of server nodes deployed for the image. Of course, the number of server nodes deployed for the container image can be set according to the actual situation, and this application does not impose specific limitations on this.

[0044] For example, upon receiving a container deployment request, the business type corresponding to each container to be deployed is obtained for subsequent steps.

[0045] Step S102: Obtain the resource utilization rate of multiple server nodes and the historical call frequency of the first container deployed on the server nodes corresponding to the target business type.

[0046] Historical call frequency can be the average daily call frequency within a recent preset time period. For example, by retrieving container call logs from the 30 days prior to the current moment, the total call frequency during that period can be obtained, and thus the average daily call frequency can be calculated. Resource utilization refers to the utilization rate of resources on a server node, including but not limited to the utilization rates of various metrics such as CPU utilization, memory utilization, disk I / O utilization, and network bandwidth utilization. The lower the resource utilization rate, the more abundant the available resources on the server node.

[0047] For example, the resource utilization of multiple server nodes and the historical call frequency of the first container deployed on the server nodes corresponding to the target business type are obtained to prepare for the use of resource utilization and historical call frequency in subsequent steps.

[0048] Step S103: Based on the resource utilization rate of each server node, obtain the target priority of each server node.

[0049] The priority of the server node indicates the priority level when deploying the container to be deployed.

[0050] For example, the target priority of a server node is obtained based on its resource utilization, which prepares the subsequent determination of the target server node for the container to be deployed.

[0051] For example, a lower resource utilization rate indicates that the server node has more available resources, and therefore a higher priority can be set. For instance, different priority ranges can be set, and based on the server node's resource utilization rate and each resource utilization range, the range to which the server node's resource utilization rate belongs can be determined, thus determining the priority corresponding to that range.

[0052] For example, considering CPU utilization ≤70% (to avoid computational bottlenecks), memory usage ≤65% (to prevent OOM errors), disk I / O usage ≤80% (to avoid read / write lag), and network bandwidth utilization ≤75% (to prevent communication latency), the percentages of different metrics on server nodes are pre-set. The utilization rates of these different metrics are then summed to obtain a server node score, and the corresponding score range is determined, with a priority set for each score range. For instance, server node score = CPU utilization × 30% + memory utilization × 30% + disk I / O utilization × 20% + network bandwidth utilization × 20%. A lower score indicates more available resources and a higher priority for the server node. Therefore, the score range corresponding to each priority can be set as follows: High-priority server nodes: score < 60 points (extremely abundant resources, suitable for high-frequency / high-priority containers). Medium-priority server nodes: score 60-79 points (relatively abundant resources, suitable for medium-frequency / medium-priority containers). Low-priority server nodes: score ≥ 80 points (resources are limited, and they will not be included in the deployment at this time).

[0053] For example, if server node A has a CPU utilization of 60%, a memory utilization of 70%, a disk I / O utilization of 90%, and a bandwidth utilization of 80%, then the server node score is 60 × 0.3 + 70 × 0.3 + 90 × 0.2 + 80 × 0.2 = 71 points. Therefore, server node A has a medium priority.

[0054] For example, the usage rate of various metrics on a server node can be obtained in real time. For instance, data can be collected every 5 seconds, and after a preset number of collections, the average usage rate of each metric can be calculated to obtain the average usage rate of each metric, which is then used to calculate the server node score.

[0055] Step S104: Based on the historical call frequency of the first container corresponding to the target business type, obtain the target call level of the first container.

[0056] The first container is a container that has been deployed and is running on the server node. The historical call frequency is the call frequency within a preset period before the current time. For example, the historical call frequency can be the average daily call frequency over the 30 days before the current time, which can be obtained through the container call logs. The call level is related to the historical call frequency; the higher the historical call frequency, the higher the call level.

[0057] In this embodiment, the target call level of the first container is determined based on the historical call frequency of the first container deployed on the server node corresponding to the target business type, so as to prepare for the subsequent determination of the target server node of the container to be deployed corresponding to the target business type.

[0058] Step S105: Based on the target business type, obtain the target container level of the container to be deployed corresponding to the target business type.

[0059] The container level is determined based on the business type, with different business types having varying degrees of importance. For example, P0 level: core business (such as payment transaction processing, 99.99% availability, interruption would cause business shutdown); P1 level: important business (such as logistics tracking, 99.9% availability, interruption can be handled by downgrading); P2 level: general business (such as data statistics, interruption only affects internal operations); P3 level: auxiliary business (such as log analysis, can be temporarily suspended), etc. It should be understood that P0-P3 levels are ordered from highest to lowest. Of course, the specific container level can be set according to the actual situation, and this application does not impose any restrictions on it.

[0060] In this embodiment, the target container level of the container to be deployed is obtained according to the target business type of the container to be deployed. The container level clarifies the business importance of the container, preparing for the subsequent determination of the target server node for the container to be deployed.

[0061] Step S106: Based on the target call level of the first container corresponding to the target business type, the target container level of the container to be deployed corresponding to the target business type, and the target priority of multiple server nodes, determine the target server node corresponding to the container to be deployed corresponding to the target business type, so as to create the container to be deployed on the target server node.

[0062] In this embodiment, the target call level of the first container corresponding to the target business type, the target container level of the container to be deployed corresponding to the target business type, and the target priority of multiple server nodes are comprehensively considered to obtain the most suitable server node for each container to be deployed, and then the container to be deployed is created on the target server node.

[0063] The technical solution of this application embodiment, upon receiving a container deployment request, first identifies the service type for which the container to be deployed serves, i.e., identifies the target service type. It collects the resource utilization rates of multiple server nodes and the historical call frequency of a first container belonging to the target service type. Based on the resource utilization rate of each server node, it obtains the target priority of each server node. Based on the historical call frequency of the first container corresponding to the target service type, it obtains the target call level of the first container. Based on the target service type, it obtains the target container level of the container to be deployed corresponding to the target service type. Based on the target priority, target call level, and target container level, it obtains the target server node corresponding to the container to be deployed corresponding to the target service type. Then, it creates the container to be deployed on the target server node, realizing the deployment of the container to be deployed in response to the container deployment request. The technical solution of this application embodiment comprehensively optimizes from multiple dimensions to determine the optimal deployment scheme. Through this dynamic and intelligent scheduling, the container is not fixed on the initially deployed server node. The new deployment will flexibly select the best location based on the current resource status of the server node and the historical behavior of the service, thereby fundamentally solving the problems of resource allocation imbalance and insufficient capacity utilization.

[0064] In some embodiments, determining the target server node corresponding to the container to be deployed, based on the target call level of the first container corresponding to the target business type, the target container level of the container to be deployed, and the target priorities of multiple server nodes, includes: obtaining multiple candidate server nodes corresponding to the container to be deployed based on a preset mapping relationship, the target call level of the first container corresponding to the target business type, the target container level of the container to be deployed, and the target priorities of multiple server nodes; and determining the target server node corresponding to the container to be deployed from the multiple candidate server nodes.

[0065] The preset mapping relationship is a pre-defined relationship between call level, container level, and server node priority. For example, a container with a high call level and high container level is mapped to a high-priority server node with more abundant resources. The mapping relationship can be set as follows: high call level and P0 / P1 level containers correspond to high-priority server nodes; medium call level and P1 / P2 level containers correspond to medium-priority server nodes; low call level and P2 / P3 level containers correspond to the remaining available server nodes. Here, P0 / P1 level represents either P0 or P1 level.

[0066] In this embodiment, based on a preset mapping relationship, the target call level, the target container level, and the target priorities of multiple server nodes, multiple candidate server nodes corresponding to the container to be deployed are obtained. The target server node is then determined from these candidate nodes. This rule-based mapping mechanism avoids blind or random server node selection, reduces decision-making complexity, and significantly improves the response speed and automation level of the deployment process. Furthermore, the preset mapping relationship essentially intelligently associates the container's business characteristics (such as usage frequency and container level) with the resource status of server nodes, ensuring the scientific and rational allocation of resources. This achieves refined management and load balancing of container cluster resources as a whole, avoiding resource skew or waste. Through initial screening, a pool of qualified candidate server nodes that aligns with the general direction is obtained. The final refined selection from this pool yields the target server node.

[0067] For example, based on this pool of candidate server nodes, different final strategies can be flexibly adopted without violating the overall scheduling principles. Random selection can be used to achieve simple load balancing, or the server node with the most abundant resources in the candidate pool, i.e., the one with the highest priority score, can be selected. Since the candidate server nodes are all qualified server nodes that have been verified by the strategy, regardless of which one is ultimately selected, the basic requirements of business and resources can be largely guaranteed to be met.

[0068] In some embodiments, determining the target server node corresponding to the container to be deployed from multiple candidate server nodes includes: determining the target server node corresponding to the container to be deployed from multiple candidate server nodes according to preset container deployment rules.

[0069] The preset container deployment rules stipulate that the ratio of the number of containers of the same business type on any server node to the total number of containers on that server node must be less than or equal to a preset occupancy threshold. For example, a server node can run a maximum of 20 containers, and the preset occupancy threshold is 30%. Therefore, on that server node, the maximum number of payment service containers cannot exceed 20 × 30% = 6. Even if the server node has sufficient resources, once the number of payment containers reaches 6, no new payment containers will be deployed on it.

[0070] In this embodiment, a proportional limit is used to force containers of the same business type to be deployed across multiple different server nodes. This ensures that even if a single server node fails, only a small portion of the instances of that business will be affected, while similar containers on other server nodes can continue to provide service. In container clusters shared by multiple users or departments, a single business department may deploy a large number of its containers on a few high-performance server nodes, thus crowding out resources from other departments and leading to unfair resource allocation. The proportional limit ensures that no single business type can monopolize any high-quality server node. This reserves deployment space for containers of other business types, institutionally guaranteeing fair sharing of container cluster resources among multiple users, making it particularly suitable for shared container platform scenarios within enterprises.

[0071] For example, a hash mapping method can be used to map user IDs to server nodes, limiting the ratio of the number of containers for a single user ID on any server node to the total number of containers on that server node to be less than or equal to a preset occupancy threshold. Here, the user ID is used to uniquely identify a user.

[0072] In some embodiments, obtaining the target call level of the first container based on the historical call frequency of the first container corresponding to the target business type includes: determining the target call frequency range in which the historical call level is located based on the historical call frequency of the first container deployed on the server node corresponding to the target business type; and determining the target call level corresponding to the target call frequency range according to the preset correspondence between call levels and call frequency ranges.

[0073] For example, call levels can be set to include high-frequency, medium-frequency, and low-frequency levels. For instance, high-frequency level: ≥5 effective calls per day (e.g., user authentication container). Medium-frequency level: 1-4 effective calls per day (e.g., order query container). Low-frequency level: ≤0 effective calls per day (e.g., test environment container). The container call behavior differs depending on the call level. For example, the user authentication container needs continuous availability and can be deployed within the order query container, where calls are made on demand. The test environment container, on the other hand, remains idle for extended periods.

[0074] For example, the call frequency range corresponding to each call level is configurable and can be flexibly adjusted according to business characteristics and container cluster size.

[0075] In this embodiment, as long as the historical call frequency fluctuates within the same range, its corresponding frequency level will not change, thus ensuring the stability of the scheduling strategy. A container will not change its frequency level due to a small, accidental change in the call volume, thereby avoiding calculation errors on the target server node.

[0076] In some embodiments, obtaining the resource utilization rate of multiple server nodes and the historical call frequency of a first container deployed on the server nodes corresponding to a target business type includes: obtaining the first resources of multiple server nodes and the second resources of multiple containers to be deployed in the container deployment request; determining the sum of multiple first resources based on the multiple first resources and the multiple second resources; and obtaining the resource utilization rate of multiple server nodes and the historical call frequency of the first container deployed on the server nodes corresponding to the target business type when the sum of the multiple first resources is greater than or equal to the sum of the multiple second resources.

[0077] In this embodiment, a global and fundamental resource feasibility check is performed first. Obtaining resource utilization, historical call frequency, and calculating server node priority, call level, and container level are relatively complex and computationally intensive. Therefore, before calculation, it is determined whether the overall resources of the container cluster can meet the deployment request, avoiding wasting CPU response time and scheduling cycles.

[0078] In some embodiments, that is, when the target server node for each container to be deployed is determined, i.e. the deployment scheme for each container to be deployed is obtained, the resource requirements of the target server node and the container to be deployed are parsed, such as CPU configuration parameters, memory capacity required, etc., and the Docker API (such as docker run) is called to create the container to be deployed on the target server node and configure resource limits, such as CPU share, memory limit, etc.

[0079] In some embodiments, CPU and memory quotas for containers are set based on control group (cgroups) technology. 10% of CPU and / or memory is reserved as a dedicated resource pool for P0-level containers and is not allocated to other containers. For example, a P0-level payment container may be allocated 0.5 CPU cores and 2GB of memory, while 10% of the server node's resources are locked (e.g., 0.8 cores of an 8-core CPU are locked).

[0080] In some embodiments, a container deployment method is provided, which can be implemented through a container deployment system. Technical terms that are the same as or similar to those in the foregoing embodiments will not be repeated. Figure 2 This is a flowchart illustrating the container deployment method according to an embodiment of this application, as shown below. Figure 2 As shown, the container deployment method in this application embodiment includes:

[0081] Step S201: Receive container deployment request.

[0082] The container deployment request includes multiple target business types corresponding to the containers to be deployed.

[0083] Step S202: Obtain the first resources of multiple server nodes and the second resources of multiple containers to be deployed in the container deployment request.

[0084] Step S203: Determine the sum of the multiple first resources based on the multiple first resources and the multiple second resources.

[0085] Step S204: If the sum of multiple first resources is greater than or equal to the sum of multiple second resources, obtain the resource utilization rate of multiple server nodes and the historical call frequency of the first container deployed on the server nodes corresponding to the target business type.

[0086] Step S205: Based on the resource utilization rate of each server node, obtain the target priority of each server node.

[0087] Step S206: Based on the historical call frequency of the first container corresponding to the target business type, obtain the target call level of the first container.

[0088] Step S207: Based on the target business type, obtain the target container level of the container to be deployed corresponding to the target business type.

[0089] Step S208: Determine the target server node corresponding to the container to be deployed that corresponds to the target business type based on the target call level of the first container corresponding to the target business type, the target container level of the container to be deployed that corresponds to the target business type, and the target priority of multiple server nodes.

[0090] Step S209: Create the container to be deployed on the target server node.

[0091] For example, a container is created by calling the Docker API through the container management engine in the container deployment system.

[0092] Step S210: Configure the resources of the container to be deployed.

[0093] For example, the resources of the container to be deployed, including CPU and / or memory, are configured through the node controller in the container deployment system.

[0094] Step S211: Verify the container startup status.

[0095] For example, verify whether the processes of the container to be deployed are running normally, whether the interfaces are normal (e.g., dockerps status is Up), and whether the health check interface ( / docker / health) returns "normal". Also verify whether resource usage meets the configuration (CPU ≤ limit, memory ≤ limit).

[0096] Step S212: Track the deployment status of the containers to be deployed and update the container cluster view.

[0097] For example, information such as the deployment server node, resource allocation, and startup time for each container is recorded. The container cluster resource view (including used resources, remaining resources, container distribution, etc.) is updated and fed back to the user interface layer (Web or API). The recorded container information is stored in a MySQL or PostgreSQL database, enabling full traceability of the deployment process and providing a foundation for subsequent dynamic adjustments. For example, users can view the successful deployment status of containers via Web or API, and the containers deployed on the target server node begin providing services.

[0098] It should be noted that steps S201-S212 in the embodiments of this application can be referred to the foregoing examples, and will not be repeated here.

[0099] The technical solution of this application embodiment constructs a systematic resource guarantee and fine-grained scheduling closed loop, fundamentally improving the deployment success rate and quality, realizing precise matching of multi-dimensional resources and business needs, optimizing cluster performance and stability, achieving automation and standardization in the deployment process, and significantly improving operation and maintenance efficiency.

[0100] In some embodiments, when the sum of multiple first resources is less than the sum of multiple second resources, the method further includes: obtaining multiple candidate first containers from the first containers of multiple server nodes, wherein the service type is non-real-time service, the container level is a preset container level, and the container idle time is greater than or equal to a first preset time; determining multiple target first containers from the multiple candidate first containers based on the second resources of the multiple containers to be deployed and the third resources of the multiple candidate first containers, and shutting down the multiple target first containers.

[0101] The settings for non-real-time services, preset container levels, and the first preset duration are determined based on actual circumstances. For example, the first container labeled "non-real-time" is selected, while containers labeled "real-time" are the first containers for real-time services, such as payment transactions and user authentication. Container labels can be queried via the Docker API, such as `docker inspect --format '{{.Config.Labels}}'<container ID>`, to exclude the first container for real-time services and avoid impacting business continuity. The preset container level can be P2 or P3, meaning the first container with a lower container level is selected to ensure that the first container with a higher container level is not shut down. The first preset duration can be 72 hours to filter out long-term idle first containers, reducing the impact of shutting down the first container on business operations.

[0102] In this embodiment, if it is determined that the resources of the current container cluster are insufficient to meet the resource requirements of each container to be deployed in the container deployment request, then the services with the least impact on user experience and real-time response are prioritized. Firstly, core services that are latency-sensitive and cannot be interrupted are excluded to ensure that resource reclamation operations do not affect the stability of online services and user experience. Further focus is placed on the first container with low business importance to ensure that even if interrupted, it will only have a limited impact on internal operations or auxiliary functions. Accurately identifying those first containers that have not been used for a long time ensures that truly redundant resources are shut down, rather than temporarily idle services. The dynamic adjustment mechanism of this embodiment solves the problem of insufficient cluster operating capacity and allocation imbalance caused by fixed deployment. The automated resource reclamation strategy ensures that in complex scenarios with multiple uses and fixed deployments, the container cluster can continuously meet the dynamic needs of business development while guaranteeing the absolute stability of core services.

[0103] In some embodiments, determining multiple target first containers from multiple candidate first containers based on the second resources of multiple containers to be deployed and the third resources of multiple candidate first containers includes: calculating the third resources of multiple candidate first containers using a target algorithm to obtain multiple target first containers from multiple candidate first containers that meet the resource requirements of the second resources of multiple containers to be deployed, wherein the target algorithm is an algorithm combining a greedy algorithm and a dynamic programming algorithm.

[0104] The greedy algorithm is used to determine an initial set of candidate first containers that meets the resource requirements of the second resources of multiple candidate first containers based on the third resources of multiple candidate first containers. The dynamic programming algorithm is used to find the optimal solution based on the initial set of candidate first containers obtained by the greedy algorithm, that is, the resource release of multiple target first containers is greater than or equal to the resource requirements of the second resources of multiple target first containers, and the number of target first containers is minimized.

[0105] In this embodiment, the greedy algorithm in the target algorithm first sorts multiple candidate first containers in descending order according to the total amount of resources that a single candidate first container can release. Starting from the first position after sorting, i.e., the candidate first container with the largest resource release, the candidate first containers are added to the set of containers to be shut down in turn. After each iteration, the total amount of first resources released in the current set of containers to be shut down is calculated. The iteration stops when the total amount of first resources reaches or exceeds the total amount of second resources required by multiple containers to be deployed. The greedy algorithm can obtain a preliminary set of containers to be shut down with a relatively small number of containers from multiple candidate first containers. It should be understood that resources may include the number of CPU cores and memory capacity, etc. Then, the dynamic programming algorithm uses the number of candidate first containers in the set of containers to be shut down provided by the greedy algorithm as the upper limit. By traversing multiple candidate first containers, it determines the optimal set of containers to be shut down with the absolute minimum number of containers. This ensures that when the container cluster resources are insufficient, an optimal set of containers to be shut down is selected from the set of candidate first containers for closure, so that the total amount of resources released by the set of containers to be shut down meets the resource requirements of multiple containers to be deployed, while ensuring that the number of containers shut down is minimized.

[0106] For example, dynamic programming can be used to precisely solve for the combination of the minimum number of containers to close, ensuring resource matching. Specifically, this involves defining a two-dimensional dynamic programming table dp[i][j], where dp[i][j] represents the minimum number of containers required to release i CPU cores and j GB of memory. The ranges of i and j are narrowed down based on the results of a greedy algorithm.

[0107] Initialization: dp[0][0]=0, indicating that releasing 0 resources requires 0 containers. Iterate through each candidate container. For each container, update the dp table. For each i and j (traverse from largest to smallest to avoid duplicate selection), calculate the new state: dp[i][j]=min(dp[i][j],dp[i-r1][j-r2]+1), where r1 is the CPU release amount of the first candidate container and r2 is the memory release amount of the first candidate container.

[0108] Traverse the dp table to find i and j that satisfy the following conditions:

[0109] i ≥ 95% of total CPU usage and j ≥ 95% of total memory usage (indicating a match rate of ≥ 95%).

[0110] The minimum value of dp[i][j] is achieved (i.e., the minimum number of containers).

[0111] Backtrack from the optimal state (i, j) and record the selected container.

[0112] Obtaining the precise optimal solution means determining the first container for multiple targets. It should be understood that total CPU refers to the total number of CPU cores required for the multiple containers to be deployed, and total memory refers to the total memory capacity required for the multiple containers to be deployed.

[0113] For example, multiple containers to be deployed require 10 CPU cores and 30GB of memory. A target algorithm combining greedy algorithm and dynamic programming algorithm is used to filter candidate first containers, resulting in 102 target first containers. Closing these target first containers can free up 10.2 CPU cores and 30.5GB of memory, satisfying the resource requirements of multiple containers to be deployed.

[0114] In some embodiments, shutting down multiple target first containers includes: sending container shutdown requests to the multiple target first containers respectively; and shutting down the target first containers if a first feedback message is received from a target first container.

[0115] The container shutdown request includes, but is not limited to, HTTP requests (such as calling the / docker / health interface) to check if the target first container has any outstanding issues, such as uncommitted database operations or unresponsive API requests. The first feedback message can return "healthy," indicating that there are no outstanding issues and the target first container can be shut down.

[0116] Specifically, container shutdown requests are sent to multiple target first containers. Upon receiving a first feedback message from the target first container agreeing to shut down, the target first container is shut down. By sending container shutdown requests, it is determined whether the target first container can be shut down at the current time on the server node, thus avoiding shutting down the first container that processes regular expression business and preventing data loss.

[0117] In some embodiments, after sending container shutdown requests to multiple target first containers respectively, the method further includes: if a second feedback message indicating that the target first container does not agree to close is received, then the container shutdown request is repeatedly sent at a second preset time interval until a preset number of times is reached or a first feedback message is received, and then the sending of the container shutdown request is stopped.

[0118] The second feedback message can be "busy," indicating that the current target container (first container) has unfinished tasks. Of course, the format and content of the first and second feedback messages can be set according to actual needs; no specific limitations are made here. The second preset duration and preset number of sends can be set according to actual needs. For example, the second preset duration can be 10 minutes, and the preset number of sends can be 3. The 10-minute interval avoids frequent checks that consume resources; if the container is still busy after 3 retries, it is excluded from consideration.

[0119] In this embodiment of the application, if a second feedback message is received, the container identifier (container ID) of the target first container is recorded, and the container shutdown request is resent after a second preset time delay. If no first feedback message is received, the container shutdown request is resent until a preset number of times is reached or the first feedback message is received, at which point the sending of the container shutdown request stops.

[0120] For example, if the first feedback message is not received after the preset sending time, it is determined whether the sum of the third resources of the target first container to be closed is greater than or equal to the sum of the second resources of the container to be deployed. If it is satisfied, the target first container that has not received the first feedback message is not closed. If it is not satisfied, a candidate first container is selected from multiple candidate first containers according to the same business type and the same container level as the target first container that has not received the first feedback message, and a container closure request is sent to replace the target first container that has not received the first feedback message.

[0121] In some embodiments, the Docker API (docker stop) is called sequentially to shut down the healthy target first container, that is, the target first container with no outstanding items, and to release the CPU, memory and disk resources occupied by the container. For example, the P3 level container is shut down first, and then the P2 level container is shut down, so as to safely release the resources for the container to be deployed.

[0122] In some embodiments, 10% of the P0-level container quota is locked for each user. After the target first container is closed, the remaining P0-level containers must not fall below this quota. For example, if a user has 100 P0-level containers, locking and closing 10 will ensure that at least 10 P0-level containers remain. When selecting candidate first containers, P0-level containers within the locked quota are automatically excluded. This ensures the minimum number of core business containers running.

[0123] In some embodiments, each server (server node) reserves 10% of its CPU and 10% of its memory as a dedicated resource pool for P0-level containers, which is not allocated to containers of other levels. For example, an 8-core CPU server reserves 0.8 cores and 32GB of memory reserves 3.2GB. Only P0-level containers can use these resources, reserving emergency resources for core containers to avoid interruptions caused by resource exhaustion.

[0124] In some embodiments, cold backups are created for all P0-level containers (storing only images, configuration files, and data volume snapshots, without consuming runtime resources). In the event of a failure of the original P0-level container, a backup container is launched within one minute via the Docker API, using a distributed storage system (such as the Ceph distributed file system) to ensure data security, enable rapid failure recovery of core containers, and guarantee availability.

[0125] In some embodiments, the released resources are allocated to the container to be deployed, the container to be deployed is created, the container cluster resource view and scheduling log are updated, and dynamic adjustment is completed. It should be noted that the specific process of creating the container to be deployed on the target server node is described in the previous example, and will not be repeated here.

[0126] In some embodiments, a container deployment method is provided. In this application embodiment, the same or similar technical terms as those in the foregoing embodiments will not be repeated. Figure 3 This is a flowchart illustrating a container deployment method provided in an embodiment of this application, as shown below. Figure 3 As shown, the method includes:

[0127] Step S301: Obtain the first resources of multiple server nodes and the second resources of multiple containers to be deployed in the container deployment request.

[0128] Step S302: Determine the sum of the multiple first resources based on the multiple first resources and the multiple second resources.

[0129] Step S303: When the sum of multiple first resources is less than the sum of multiple second resources, obtain multiple candidate first containers from the first containers of multiple server nodes. The first containers are of non-real-time business type, the container level is a preset container level, and the container idle time is greater than or equal to the first preset time.

[0130] Step S304: Calculate the third resources of multiple candidate first containers using the target algorithm, and obtain multiple target first containers from the multiple candidate first containers that meet the resource requirements of the second resources of multiple containers to be deployed.

[0131] Step S305: Detect whether there are any unfinished items in the first target container. If yes, proceed to step S306; otherwise, proceed to step S308.

[0132] The method to check whether there are any unfinished items in the target first container can be by sending a container closure request to the target first container. If a first feedback message is received, it means that there are no unfinished items in the target first container. If a second feedback message is received, it means that there are unfinished items in the target first container.

[0133] Step S306: Repeat the check after a second preset time interval.

[0134] In step S307, if the preset number of transmissions is reached and the check result of the target first container still indicates that there are incomplete items, the check is stopped and the target first container is deleted from the target combination method. Then step S309 can be executed.

[0135] Step S308: Close the target first container and release resources.

[0136] Step S309: Activate the core container protection mechanism.

[0137] For example, a core container protection mechanism is activated, including cold backup (backup can be initiated within 1 minute in case of P0 container failure), resource reservation (10% CPU and / or memory is reserved for P0-level containers on each server node), and quota locking (10% of P0-level containers are reserved for users). This core container protection mechanism prevents subsequent container creation and other operations from affecting core containers. For details on cold backup, resource reservation, and quota locking, please refer to the aforementioned example; they will not be repeated here.

[0138] It should be noted that in the embodiments of this application, steps S301-S309 can refer to the aforementioned example, and will not be repeated here.

[0139] The technical solution in this application forms a complete automated closed loop, from resource shortage detection to intelligent decision-making and secure execution and protection. Operations personnel no longer need to manually intervene to find containers that can be shut down or worry about impacting business operations, greatly reducing operational complexity and management costs.

[0140] In some embodiments, a container deployment system is provided that can implement the container deployment method in the above embodiments. In this application, the same or similar technical terms as those in the foregoing embodiments will not be repeated.

[0141] Figure 4 This is a schematic diagram of the structure of a container deployment system provided in an embodiment of this application, as shown below. Figure 4 The container deployment system 400 of this application embodiment includes: a request receiving module 401, a first acquisition module 402, a second acquisition module 403, a third acquisition module 404, a fourth acquisition module 405, and a deployment module 406, wherein:

[0142] The request receiving module 401 is used to receive container deployment requests, which include multiple target business types corresponding to containers to be deployed; the first acquisition module 402 is used to acquire the resource utilization of multiple server nodes and the historical call frequency of the first container already deployed on the server nodes corresponding to the target business type; the second acquisition module 403 is used to obtain the target priority of each server node based on the resource utilization of each server node; the third acquisition module 404 is used to obtain the target call level of the first container based on the historical call frequency of the first container corresponding to the target business type; the fourth acquisition module 405 is used to obtain the target container level of the container to be deployed corresponding to the target business type based on the target business type; and the deployment module 406 is used to determine the target server node corresponding to the container to be deployed corresponding to the target business type based on the target call level of the first container corresponding to the target business type, the target container level of the container to be deployed corresponding to the target business type, and the target priority of multiple server nodes, so as to create the container to be deployed on the target server node.

[0143] The technical solution of this application embodiment, upon receiving a container deployment request, first identifies the service type for which the container to be deployed serves, i.e., identifies the target service type. It collects the resource utilization rates of multiple server nodes and the historical call frequency of a first container belonging to the target service type. Based on the resource utilization rate of each server node, it obtains the target priority of each server node. Based on the historical call frequency of the first container corresponding to the target service type, it obtains the target call level of the first container. Based on the target service type, it obtains the target container level of the container to be deployed corresponding to the target service type. Based on the target priority, target call level, and target container level, it obtains the target server node corresponding to the container to be deployed corresponding to the target service type. Then, it creates the container to be deployed on the target server node, realizing the deployment of the container to be deployed in response to the container deployment request. The technical solution of this application embodiment comprehensively optimizes from multiple dimensions to determine the optimal deployment scheme. Through this dynamic and intelligent scheduling, the container is not fixed on the initially deployed server node. The new deployment will flexibly select the best location based on the current resource status of the server node and the historical behavior of the service, thereby fundamentally solving the problems of resource allocation imbalance and insufficient capacity utilization.

[0144] This application also provides an electronic device, including a processor and a memory; the memory stores program instructions, which, when executed by the processor, cause the electronic device to perform the container deployment method in any of the above embodiments.

[0145] This application also provides a computer-readable storage medium including computer instructions that, when executed on the electronic device, cause the electronic device to perform various functions or steps performed by the electronic device in the above method embodiments.

[0146] This application also provides a computer program product that, when run on a computer, causes the computer to perform various functions or steps performed by the electronic device in the above method embodiments.

[0147] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the system can be divided into different functional modules to complete all or part of the functions described above.

[0148] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of systems or units may be electrical, mechanical, or other forms.

[0149] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0150] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0151] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0152] 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 within the technical scope 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.

Claims

1. A method of deploying a container, characterized by, include: Receive a container deployment request, wherein the container deployment request includes multiple target business types corresponding to containers to be deployed; Obtain the resource utilization rate of multiple server nodes and the historical call frequency of the first container deployed on the server nodes corresponding to the target business type; Based on the resource utilization rate of each server node, the target priority of each server node is obtained. Based on the historical call frequency of the first container corresponding to the target business type, the target call level of the first container is obtained; Based on the target business type, the target container level of the container to be deployed corresponding to the target business type is obtained; Based on the target call level of the first container corresponding to the target business type, the target container level of the container to be deployed corresponding to the target business type, and the target priority of the multiple server nodes, the target server node corresponding to the container to be deployed corresponding to the target business type is determined, so as to create the container to be deployed on the target server node; The step of obtaining the resource utilization rate of multiple server nodes and the historical call frequency of the first container deployed on the server nodes corresponding to the target business type includes: Obtain the first resources of the plurality of server nodes and the second resources of the plurality of containers to be deployed in the container deployment request; Based on the plurality of first resources and the plurality of second resources, determine the sum of the plurality of first resources; If the sum of the plurality of first resources is greater than or equal to the sum of the plurality of second resources, obtain the resource utilization rate of the plurality of server nodes and the historical call frequency of the first container deployed on the server nodes corresponding to the target business type; If the sum of the plurality of first resources is less than the sum of the plurality of second resources, multiple candidate first containers are obtained from the first containers of the plurality of server nodes, wherein the service type is non-real-time service, the container level is a preset container level, and the container idle time is greater than or equal to a first preset time. Based on the second resources of the plurality of containers to be deployed and the third resources of the plurality of candidate first containers, a plurality of target first containers are determined from the plurality of candidate first containers, and the plurality of target first containers are shut down.

2. The method of claim 1, wherein, The step of determining the target server node corresponding to the container to be deployed corresponding to the target business type based on the target call level of the first container corresponding to the target business type, the target container level of the container to be deployed corresponding to the target business type, and the target priority of the multiple server nodes includes: Based on the preset mapping relationship, the target call level of the first container corresponding to the target business type, the target container level of the container to be deployed corresponding to the target business type, and the target priority of the multiple server nodes, multiple candidate server nodes corresponding to the container to be deployed are obtained. The target server node corresponding to the container to be deployed is determined from the plurality of candidate server nodes; The preset mapping relationship is a pre-defined relationship between the call level, container level, and server node priority.

3. The method of claim 2, wherein, The step of determining the target server node corresponding to the container to be deployed from the plurality of candidate server nodes includes: According to the preset container deployment rules, the target server node corresponding to the container to be deployed is determined from the plurality of candidate server nodes; The preset container deployment rule includes a ratio of the number of containers of the same business type on any server node to the total number of containers on the server node being less than or equal to a preset occupancy threshold.

4. The container deployment method according to claim 1, characterized in that, The step of obtaining the target call level of the first container based on the historical call frequency of the first container corresponding to the target service type includes: Based on the historical call frequency of the first container deployed on the server node corresponding to the target business type, determine the target call frequency range of the historical call level; Based on the preset correspondence between call levels and call frequency ranges, the target call level corresponding to the target call frequency range is determined.

5. The container deployment method according to claim 1, characterized in that, The step of determining multiple target first containers from the multiple candidate first containers based on the second resources of the multiple containers to be deployed and the third resources of the multiple candidate first containers includes: The third resource of the plurality of candidate first containers is calculated by a target algorithm, and a plurality of target first containers that meet the resource requirements of the second resource of the plurality of containers to be deployed are obtained from the plurality of candidate first containers. The target algorithm is an algorithm that combines a greedy algorithm and a dynamic programming algorithm.

6. The container deployment method according to claim 1, characterized in that, The closure of the plurality of target first containers includes: Send container shutdown requests to multiple target first containers respectively; If a first feedback message is received from the target first container, then the target first container is closed.

7. The container deployment method according to claim 6, characterized in that, After sending container shutdown requests to multiple target first containers respectively, the method further includes: If a second feedback message is received from the target first container, the container shutdown request is repeatedly sent at a second preset time interval until a preset number of times is reached or the first feedback message is received, at which point the sending of the container shutdown request stops.

8. A container deployment system, characterized in that, include: The request receiving module is used to receive container deployment requests, wherein the container deployment requests include multiple target business types corresponding to containers to be deployed; The first acquisition module is used to acquire the resource utilization rate of multiple server nodes and the historical call frequency of the first container deployed on the server nodes corresponding to the target business type; The second acquisition module is used to obtain the target priority of each server node based on the resource utilization rate of each server node. The third acquisition module is used to obtain the target call level of the first container based on the historical call frequency of the first container corresponding to the target business type; The fourth acquisition module is used to obtain the target container level of the container to be deployed corresponding to the target business type based on the target business type; The deployment module is used to determine the target server node corresponding to the container to be deployed corresponding to the target business type based on the target call level of the first container corresponding to the target business type, the target container level of the container to be deployed corresponding to the target business type, and the target priority of the multiple server nodes, so as to create the container to be deployed on the target server node. The first acquisition module is further configured to: Obtain the first resources of the plurality of server nodes and the second resources of the plurality of containers to be deployed in the container deployment request; Based on the plurality of first resources and the plurality of second resources, determine the sum of the plurality of first resources; If the sum of the plurality of first resources is greater than or equal to the sum of the plurality of second resources, obtain the resource utilization rate of the plurality of server nodes and the historical call frequency of the first container deployed on the server nodes corresponding to the target business type; If the sum of the plurality of first resources is less than the sum of the plurality of second resources, multiple candidate first containers are obtained from the first containers of the plurality of server nodes, wherein the service type is non-real-time service, the container level is a preset container level, and the container idle time is greater than or equal to a first preset time. Based on the second resources of the plurality of containers to be deployed and the third resources of the plurality of candidate first containers, a plurality of target first containers are determined from the plurality of candidate first containers, and the plurality of target first containers are shut down.

Images