Container scheduling method and related equipment

Abstract

The invention provides a container scheduling method and related equipment, which are used for improving the reliability of services. The method is applied to a cloud platform, and the cloud platform is used for managing a server cluster. The method comprises the steps that a first request is acquired, the first request comprises at least one maximum resource parameter value of at least one container and at least one service level corresponding to the at least one container, and the at least one service level comprises a high-priority service; according to the at least one maximum resource parameter value and the at least one service level, the at least one container is scheduled to a target server, the target server is contained in a server cluster, and at most part or all of resources which can be allocated by the target server are allocated to all high-priority service containers scheduled by the target server to be used.

Description

Technical Field

[0001] This application relates to the field of cloud computing, and in particular to a container scheduling method and related equipment. Background Technology

[0002] Kubernetes is an open-source application for managing containerized applications on hosts in cloud platforms, serving as a general-purpose foundation for container orchestration. It is often abbreviated as K8s and provides a mechanism for application deployment, planning, updating, and maintenance.

[0003] The relevant technical solutions define container resources, including requests and limits used by the containers. Requests represent the minimum resources a container can acquire, while limits represent the maximum resources a container can acquire when a node is idle. When scheduling containers, the container scheduling request sent to the cloud platform includes the resource definition for each container, enabling the cloud server to allocate resources accordingly.

[0004] In this technical solution, the resource range used by the container is defined based on requests and limits, but the value of limits is not restricted. During a surge in business traffic or program failure, the container's resource consumption may increase sharply due to excessively high limits, leading to node overload, which in turn reduces service quality or even makes the service unavailable. Summary of the Invention

[0005] This application provides a container scheduling method and related equipment. When scheduling at least one container to a target server, the method references the service level and maximum resource parameter value of the at least one container. It limits the allocation of at most some or all of the resources available on the target server to all high-priority containers scheduled to the target server. Therefore, even if the resources used by high-priority service containers reach the maximum resource parameter value, there are still available resources on the target server, or the needs of the high-priority service containers can still be met, preventing node overload and ensuring service quality and reliability.

[0006] Firstly, this application provides a container scheduling method applied to a cloud platform that manages a server cluster. The cloud platform receives a first request, which includes at least one maximum resource parameter value for at least one container and at least one service level corresponding to at least one container. The at least one service level includes high-priority services. The maximum resource parameter value refers to the maximum resource value that a container can use when server resources are sufficient. Each container has its own service level. The first request is used to request the cloud platform to schedule at least one container. The cloud platform schedules at least one container to a target server based on the at least one maximum resource parameter value and the at least one service level. The target server is contained within the server cluster and is some or all of the servers in the server cluster. Furthermore, the cloud platform allocates at most some or all of the allocatable resources of the target server to containers using all high-priority services scheduled by the target server. The allocatable resources of the target server refer to all resources available for containers to use on the target server. Containers using all high-priority services scheduled by the target server include containers using high-priority services already scheduled on the target server before receiving the first request and containers using high-priority services indicated by the first request. In this application, the types of idle resources include computing resources, storage resources, etc., which are not specifically limited here.

[0007] In this application, when scheduling at least one container to a target server, the service level and maximum resource parameter value of the at least one container are taken into account. This limits the allocation of at most some or all of the resources available on the target server to all high-priority containers scheduled to the target server. Therefore, even if the resources used by high-priority service containers reach the maximum resource parameter value, there are still available resources on the target server, or the needs of the high-priority service containers can still be met, preventing node overload and ensuring service quality and reliability.

[0008] In some optional implementations of the first aspect, at least one service level also includes low-priority services. This means that the first request actually includes information about multiple containers, each including its maximum resource parameter value and service level. Of the multiple containers requested to be scheduled by the first request, some containers provide high-priority services, and others provide low-priority services. The difference between the target server's allocable resources and the sum of the maximum resource parameter values ​​of all containers scheduling high-priority services by the target server is multiplied by N and allocated to all containers scheduling low-priority services by the target server, where N > 1. All containers scheduling low-priority services by the target server include containers already scheduled for low-priority services before the first request was obtained and containers indicating low-priority services in the first request. N > 1 means that the resources actually allocated to containers of low-priority services are greater than the remaining allocable resources of the target server. Here, the remaining allocable resources of the target server refer to the difference between the target server's allocable resources and the sum of the maximum resource parameter values ​​of all containers scheduling high-priority services by the target server; this can also be referred to as the allocable resources of containers of low-priority services.

[0009] In this application, the remaining allocable resources of the target server are over-allocated N times to containers of all low-priority services scheduled by the target server, so that the target server can schedule a larger number of containers, thereby issuing a larger number of low-priority services and further improving the resource utilization of the target server.

[0010] In some optional implementations of the first aspect, part or all of the allocatable resources of the target server is x%, where x is (0, 100). The cloud platform also obtains the actual resource utilization rate and resource utilization threshold of the server cluster. Based on the actual resource utilization rate and resource utilization threshold, it adjusts at least one of x or N.

[0011] In this application, x and N are adjustable, which means that the resources allocated by the target server to high-priority containers and low-priority containers are adjustable. This allows for dynamic adjustment of the resources available to containers of different priorities based on actual conditions, resulting in higher resource utilization of the target server.

[0012] In some optional implementations of the first aspect, the resource utilization threshold includes a minimum resource utilization threshold and a maximum resource utilization threshold. The minimum resource utilization threshold, also known as the low-water mark, represents the lowest acceptable resource utilization rate or slightly higher than the minimum. In other words, if the actual resource utilization rate is lower than this threshold, it indicates that the current server cluster's resource utilization is too low. The maximum resource utilization threshold, also known as the high-water mark, represents the highest acceptable resource utilization rate or slightly lower than the maximum. In other words, if the actual resource utilization rate is higher than this threshold, it indicates that the current server cluster's resource utilization is too high. The cloud platform adjusts at least one of x or N based on the actual resource utilization rate and the resource utilization threshold. Specifically, this includes: in schemes where the actual resource utilization rate is less than or equal to the minimum resource utilization threshold, increasing N and / or decreasing x; in schemes where the actual resource utilization rate is greater than or equal to the maximum resource utilization threshold, decreasing N and / or increasing x. Furthermore, it should be noted that the actual resource utilization rate of the server cluster can be determined by statistically analyzing the actual resource utilization rate of each server in the cluster. The resource utilization threshold is not only the overall resource utilization threshold of the server cluster, but also the resource utilization threshold for each server within the cluster; that is, each server in the cluster uses a uniform resource utilization threshold. In this application, the cloud platform adjusts x and / or N based on the actual resource utilization rate and the resource utilization threshold, making the resource allocation to high-priority and low-priority containers in the server cluster more aligned with the needs of actual applications, thus improving the feasibility of the technical solution presented in this application.

[0013] In some optional implementations of the first aspect, the actual resource utilization rate being less than or equal to the minimum resource utilization threshold can have several possibilities. It could be that the actual resource utilization rate of some servers in the server cluster is less than the minimum resource utilization threshold, while the resource utilization threshold of another group of servers falls between the minimum and maximum resource utilization thresholds. Alternatively, the server cluster could include servers with actual resource utilization rates less than the minimum threshold and servers with resource utilization thresholds greater than the maximum threshold. In some optional implementations of the first aspect, the resource utilization threshold includes both the minimum and maximum resource utilization thresholds. The cloud platform adjusts at least one of x or N based on the actual resource utilization rate and the resource utilization threshold. This may further include: in a scheme where the actual resource utilization rate is greater than the minimum resource utilization threshold, if the resources used by all containers of high-priority services called by the server cluster are x% of the server's allocatable resources, then x is increased, allowing the server cluster to accommodate a larger number of high-priority containers.

[0014] In this application, the cloud platform can also increase x to allow the server cluster to accommodate a larger number of high-priority containers, thereby providing a larger number of high-priority services.

[0015] In some optional implementations of the first aspect, the first request also includes at least one minimum resource parameter value for at least one container. The minimum resource parameter value represents the minimum amount of resources required by the container, or in other words, the minimum amount of resources the container can use. After obtaining the first request, the cloud platform can modify the minimum resource parameter value based on the different priorities of the containers. Specifically, the minimum resource parameter value of the container providing a high-priority service among the at least one containers is modified to the maximum resource parameter value of the container providing the high-priority service. That is, for the modified container providing the high-priority service, the minimum resource parameter value is equal to the maximum resource parameter value. The cloud platform also modifies the minimum resource parameter value of the container providing a low-priority service among the at least one containers to be much smaller than the maximum resource parameter value of the container providing the low-priority service. That is, for the modified container providing the low-priority service, the minimum resource parameter value is much smaller than the maximum resource parameter value.

[0016] In this application, for containers providing modified high-priority services, the minimum resource parameter value is equal to the maximum resource parameter value. This means that the container can only use the maximum resource parameter value, thus ensuring the reliability of high-priority services. For containers providing modified low-priority services, the minimum resource parameter value is much smaller than the maximum resource parameter value. Since kubenetes' native scheduling policy limits the allocatable resources of the server cluster to be greater than or equal to the sum of the minimum resource parameter values ​​of all containers, this modification allows the server cluster to deploy a larger number of containers.

[0017] In some optional implementations of the first aspect, the cloud platform obtains a second request before obtaining the first request. The second request includes at least one initial maximum resource parameter value and at least one service level for at least one container. That is, the second request can be understood as the initial request obtained by the cloud platform for requesting container scheduling. If the service of at least one container includes the same target service as the historical service, and the initial maximum resource parameter value of the target service included in the second request is not included in the resource parameter range of the historical service, it means that the initial maximum resource parameter value of the target service in the second request is unreasonable. The cloud platform sends a first message indicating that it refuses to create at least one container corresponding to the second request.

[0018] In this application, for unreasonable requests, the cloud platform will refuse to create at least one container corresponding to the request, thereby ensuring that the creation of containers meets the needs of actual applications and improving the practicality of the technical solution of this application.

[0019] In some optional implementations of the first aspect, the first message also includes a recommended maximum resource value for the target container, which is used to provide the target service. That is, while refusing to create the target container, the cloud platform also recommends the maximum resource parameter value for the target container. Therefore, the maximum resource parameter value of the target container in the first request is the recommended maximum resource value. For the initiator of the first request (i.e., the terminal), this means modifying the initial maximum resource parameter value of the target container in the second request based on the first message, and then sending the first request to the cloud platform again.

[0020] In some optional implementations of the first aspect, after sending the first message, the cloud platform also sends a second message. This second message includes the recommended maximum resource value for the target container, which is used to provide the target service. In other words, the cloud platform recommends the maximum resource parameter value for the target container after initially refusing to create it. Therefore, the maximum resource parameter value of the target container in the first request is the recommended maximum resource value. For the initiator of the first request (i.e., the terminal), this means modifying the initial maximum resource parameter value of the target container in the second request based on the second message before sending the first request to the cloud platform again.

[0021] In this application, the cloud platform, while or after refusing to create at least one container corresponding to the second request, can send a recommended maximum resource value for the target container. This allows the terminal to modify the initial maximum resource parameter value of the target container based on the recommended maximum resource value, thus obtaining the first request. The cloud platform can send the recommended maximum resource value of the target container in various ways, enriching the implementation methods and application scenarios of the technical solution in this application. Furthermore, carrying the recommended maximum resource value of the target container in the first message can reduce the number of messages transmitted between the cloud platform and the terminal, thereby reducing the consumption of communication resources.

[0022] Secondly, this application provides a cloud platform for managing server clusters, the cloud platform comprising:

[0023] The transceiver unit is used to obtain a first request, the first request including at least one maximum resource parameter value of at least one container and at least one service level corresponding to at least one container, the at least one service level including high priority service.

[0024] The processing unit is configured to schedule at least one container to a target server based on the maximum resource parameter value of at least one container and at least one service level, the target server being contained in the server cluster, and to allocate at most part or all of the allocatable resources of the target server to containers of all high-priority services scheduled by the target server.

[0025] The cloud platform is used to implement the method shown in the first aspect or any possible implementation of the first aspect.

[0026] Thirdly, this application provides a computing device including a processor and a memory. The processor of the computing device is used to execute instructions stored in the memory, causing the computing device to implement the method shown in the first aspect or any possible implementation of the first aspect.

[0027] Fourthly, this application provides a computing device cluster, including at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster implements the method disclosed in the first aspect and any possible implementation of the first aspect.

[0028] Fifthly, this application provides a computer program product containing instructions that, when executed by a cluster of computer devices, cause the cluster of computer devices to implement the method disclosed in the first aspect and any possible implementation of the first aspect.

[0029] In a sixth aspect, this application provides a computer-readable storage medium storing computer program instructions that, when executed by a cluster of computer devices, cause the cluster of computer devices to implement the method disclosed in the first aspect and any possible implementation of the first aspect.

[0030] The beneficial effects shown in any of the second to sixth aspects are similar to those of the first aspect or any possible implementation of the first aspect, and will not be repeated here. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of the system architecture provided for an embodiment of this application;

[0032] Figure 2 A flowchart illustrating the container scheduling method provided in this application embodiment;

[0033] Figure 3 Another flowchart illustrating the container scheduling method provided in this application embodiment;

[0034] Figure 4 A schematic diagram of the structure of the cloud platform provided in the embodiments of this application;

[0035] Figure 5 Another flowchart illustrating the container scheduling method provided in this application embodiment;

[0036] Figure 6 Another schematic diagram of the cloud platform provided in the embodiments of this application;

[0037] Figure 7A schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0038] Figure 8 A schematic diagram of the structure of a computing device cluster provided in an embodiment of this application;

[0039] Figure 9 This is another schematic diagram of the computing device cluster provided in an embodiment of this application. Detailed Implementation

[0040] This application provides a container scheduling method and related equipment. When scheduling at least one container to a target server, the method references the service level and maximum resource parameter value of the at least one container. It limits the allocation of a maximum of x% of the target server's allocable resources to all high-priority containers scheduled on that target server, where x is (0, 100). In other words, high-priority service containers use some or all of the target server's allocable resources. Therefore, even if the high-priority service containers use resources up to their maximum resource parameter value, there are still available resources on the target server, or the needs of the high-priority service containers can still be met, preventing node overload and ensuring service reliability without affecting service quality.

[0041] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0042] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of units is not necessarily limited to those units, but may include other units not explicitly listed or inherent to those processes, methods, products, or apparatuses. Additionally, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can be expressed as: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0043] First, the proper nouns and related concepts that may be involved in the embodiments of this application will be explained.

[0044] 1) kubernetes, kubelet, pod:

[0045] Kubernetes, or K8s for short, is an open-source system for managing containerized applications across multiple hosts in a cloud platform. It provides mechanisms for application deployment, planning, updating, and maintenance, aiming to make deploying containerized applications simple and efficient. In the container scheduling method provided in this application embodiment, the cloud platform uses the Kubernetes system to manage the scheduled containers on the server.

[0046] Kubelet is a crucial component in a Kubernetes cluster, running on each server and responsible for managing containers and pods on those servers. Kubelet ensures pods function as expected by monitoring container status and communicating with the Application Programming Interface (API) server. It can also start, stop, or restart containers on the server as needed. Furthermore, kubelet monitors server status and reports it to the API server.

[0047] A pod is the smallest unit in a Kubernetes cluster that runs and deploys applications or services, and it can support multiple containers. In other words, multiple containers can share a network address and file system within a single pod, providing services through inter-process communication and file sharing.

[0048] 2) Webhook:

[0049] Webhooks are a method of adding or changing table items on a webpage by using custom callback functions. These callback functions can be saved, modified, and managed by third-party users or developers associated with the original website or application.

[0050] 3) Cloud platform and infrastructure:

[0051] The cloud platform is used to manage the infrastructure of cloud vendors. The infrastructure consists of multiple cloud data centers located in different regions, with each region having at least one cloud data center. The cloud platform can provide interfaces related to cloud computing services, such as configuration pages (i.e., interfaces) or APIs, for tenants to access cloud services. Tenants can log in to the cloud management platform with a pre-registered account and password, and after successful login, select and purchase cloud services provided by the cloud data centers in the designated region. Cloud services include object storage services, virtual machine services, container services, or other known cloud services.

[0052] 4) Tenants:

[0053] The top-level object is used to manage cloud services and / or cloud resources. Tenants register tenant accounts and set tenant passwords on the cloud platform through local clients (such as browsers). Local clients remotely log in to the cloud platform through tenant accounts and set tenant passwords. The cloud platform provides a configuration interface or API for tenants to configure and use cloud services, where cloud services are specifically provided by the infrastructure managed by the cloud management platform as described above.

[0054] Please refer to the following. Figure 1 , Figure 1 This is a schematic diagram of the system architecture provided for an embodiment of this application.

[0055] like Figure 1 As shown, the tenant logs into the cloud platform 30 via client 10 through the Internet 20 using the account and password registered on the cloud platform 30. The cloud platform 30 manages the infrastructure, which includes multiple data centers located in different regions, such as... Figure 1Region 1, as shown, includes Cloud Data Center 1 and Cloud Data Center 2, while Region 2 includes Cloud Data Center 3 and Cloud Data Center 4. Each cloud data center has multiple servers, on which business instances (including at least one of virtual machines, containers, and dedicated hosts) run.

[0056] In this embodiment, a container management service is deployed in the business instance. After a tenant purchases cloud services through client 10 on cloud platform 30, it sends a call request to cloud platform 30. This call request is used to request cloud services from cloud platform 30. The specific content of the cloud services includes services such as container invocation and container management, which will be described in detail later and will not be repeated here.

[0057] It should be noted that the container scheduling method provided in this application can be applied to various scenarios, including public cloud scenarios, private cloud scenarios, and edge cloud scenarios. It can be deployed as a container deployment and scheduling platform or other products in customer data centers or cloud computing vendor data centers to provide services to the outside world in the form of cloud services. Cloud services can be sold based on the subscription method described above, or they can be sold in the form of software licenses; the specific method is not limited here.

[0058] Please refer to the following. Figure 2 , Figure 2 A flowchart illustrating the container scheduling method provided in this application embodiment includes:

[0059] 201. Obtain a first request, the first request including at least one maximum resource parameter value of at least one container and at least one service level corresponding to at least one container, the at least one service level including high priority service.

[0060] The container scheduling method provided in this application is applied to a cloud platform. The cloud platform manages a server cluster and manages the containers scheduled on the server cluster based on a container management system. The server cluster includes at least one server. The cloud platform establishes a communication connection with a terminal and receives a first request sent by the terminal. This first request requests the cloud platform to deploy at least one container corresponding to the first request through its managed server cluster. The first request requests the cloud platform to deploy at least one service corresponding to at least one container through its managed server cluster.

[0061] For example, taking Kubernetes as a container management system, the first request may include one or more pods, each pod comprising a set of containers. A pod includes a service level and the maximum resource parameter values ​​for each container within that pod's set of containers. The service level of each container is defined by the pod in which that container resides. In other words, each pod carries information including a service level and a set of maximum resource parameter values. This service level is the service level corresponding to each container within that pod. This set of maximum resource parameter values ​​is the maximum resource parameter value for that set of containers. Furthermore, each pod corresponds to a service, meaning that the set of containers within each pod provides a service corresponding to the pod in which that set of containers resides. Or, the service is deployed on the set of containers within a pod. Therefore, the service level of a pod is the service level of each container within that pod. The set of containers within a pod can be one or more containers.

[0062] For example, suppose the target pod includes a container 1. This target pod includes a service level and a maximum resource parameter value. The service level is the service level of container 1, and the maximum resource parameter value is the maximum resource parameter value of container 1.

[0063] For example, suppose the target pod consists of two containers, container 1 and container 2. This target pod includes a service level and two maximum resource parameter values. The service level can be understood as the service level of container 1 and container 2, respectively. The two maximum resource parameter values ​​are the maximum resource parameter values ​​for container 1 and container 2, respectively.

[0064] It should be noted that in a pod containing multiple containers, the maximum resource parameter values ​​for each container can be the same or different; this is not limited here. In general, the first request includes at least one maximum resource parameter value for at least one container and at least one service level corresponding to at least one container. Each container corresponds to a maximum resource parameter value and a service level. The maximum resource parameter value refers to the maximum resource value that the container can use when server resources are sufficient, and the service level indicates the level of service provided by the container. Among the at least one container indicated by the first request, there is a container providing high-priority services; this container can be referred to as a high-priority container.

[0065] In this application, the resources mentioned in the embodiments can be computing resources or storage resources. Computing resources include various types of processor resources, such as central processing units (CPUs), graphics processing units (GPUs), and neural processing units (NPUs). Similarly, storage resources can also be various, including memory, hard disks, disks, optical discs, cloud storage, etc., and are not specifically limited here.

[0066] 202. Based on at least one maximum resource parameter value and at least one service level, schedule at least one container to a target server, the target server being included in the server cluster, and at most some or all of the resources available on the target server being allocated to containers of all high-priority services scheduled on the target server.

[0067] After receiving the first request, the cloud platform, taking into account the parameters included in the first request, determines the target server from the server cluster managed by the cloud platform for scheduling at least one container. The parameters included in the first request refer to the maximum resource parameter values ​​and service levels included in the first request. The target server can be some or all of the servers in the server cluster.

[0068] Specifically, based on the first request, the cloud platform identifies containers with a high-priority service level from at least one container, i.e., determines the high-priority containers. Combining this with the first request, the maximum resource parameter value of the high-priority containers is obtained. The cloud platform then obtains the resource usage information of the server cluster and, based on the maximum resource parameter value of the high-priority containers, allocates at most a portion or all of the allocatable resources of the target server to all containers of high-priority services scheduled by the target server. In other words, at most x% of the allocatable resources of the target server are allocated to all containers of high-priority services scheduled by the target server, where x is (0, 100).

[0069] The value of x can be set based on prior experience, manually, or determined based on the resource scale and historical scheduling strategy of the server cluster. No specific restrictions are imposed here.

[0070] The target server schedules all high-priority service containers, including the high-priority containers indicated in the first request, and those already scheduled on the target server before the first request was received. In other words, for all high-priority containers scheduled by the target server, the resources allocated by the cloud platform satisfy the following:

[0071] The resources allocated to the high-priority container are less than or equal to x% of the resources available on the target server…(1)

[0072] Here, the allocatable resources of the target server refer to all the resources available for use by the container on the target server. x% of the allocatable resources of the target server can also be understood as the resources that the target server can allocate to high-priority containers, referred to as the allocatable resources of high-priority containers. Therefore, the aforementioned inequality (1) can also be expressed as:

[0073] The allocated resources of the high-priority container are less than or equal to x% of the allocatable resources of the target server, which is equal to the allocatable resources of the high-priority container…(2)

[0074] Furthermore, the resources allocated to high-priority containers are actually the sum of the maximum resource parameter values ​​of the high-priority containers. Therefore, the aforementioned inequality (1) can also be expressed as:

[0075] sum(maximum resource parameter value of high-priority container) ≤ x% of the target server's allocable resources…(3)

[0076] The maximum resource parameter value of a container represents the maximum resource value that a container can use when server resources are sufficient. Combining this with the aforementioned inequality, it can be seen that the target server scheduled by the cloud platform can meet the operational requirements of high-priority containers, ensuring their normal operation.

[0077] The resource usage of the aforementioned server cluster includes information such as the current resource utilization rate and allocable resources for each server in the cluster, which is not specifically limited here. In some optional implementations, when selecting a target server from the server cluster, the cloud platform may prioritize servers with low current resource utilization, or prioritize servers with high allocable resources, or select servers in other ways that can balance the resource usage of each server in the cluster, which is not specifically limited here.

[0078] In this embodiment, when scheduling at least one container to a target server, the service level and maximum resource parameter value of the at least one container are referenced. This limits the allocation of at most some or all of the target server's allocable resources to all high-priority containers scheduled by the target server. Therefore, even if the resources used by high-priority service containers reach their maximum resource parameter value, the target server still has available resources in the scheme of allocating at most a portion of the target server's resources to all high-priority containers scheduled by the target server. In the scheme of allocating at most all of the target server's resources to all high-priority containers scheduled by the target server, the target server can still meet the needs of high-priority service containers, without causing node overload, thus not affecting service quality and ensuring service reliability.

[0079] In some optional implementations, the first request may include at least one service level that also includes a low-priority service, and the container providing the low-priority service may be referred to as a low-priority container. In the embodiments of this application, the service priority can be set based on the actual application, and may be preset or manually specified; no specific limitation is made here.

[0080] For low-priority containers, the cloud platform employs a resource allocation mechanism, ensuring that the resources allocated to low-priority containers exceed their available allocable resources. In other words, for all low-priority containers scheduled by the target server, the resources allocated by the cloud platform satisfy the following conditions:

[0081] Low-priority container allocable resources × N ≥ Low-priority container already allocated resources…(4)

[0082] It is understandable that the allocatable resources of the target server are allocated to both high-priority and low-priority containers it schedules. Therefore, the allocatable resources for low-priority containers in the aforementioned inequality (4) are actually the difference between the allocatable resources of the target server and the allocated resources of all high-priority containers scheduled by the target server. Thus, the aforementioned inequality (4) can also be expressed as:

[0083] (Target server available resources - resources already allocated to high-priority containers) × N ≥ resources already allocated to low-priority containers…(5)

[0084] The difference between the resources available for allocation on the target server and the resources already allocated to high-priority containers can also be referred to as the remaining available resources on the target server.

[0085] Furthermore, the resources allocated to low-priority containers are actually the sum of the maximum resource parameter values ​​of the low-priority containers. Therefore, the aforementioned inequality (5) can also be expressed as:

[0086] (Target server available resources - resources already allocated to high-priority containers) × N ≥ sum(maximum resource parameter value of low-priority containers)...(6)

[0087] Combining the aforementioned inequalities (1) and (3), it can be seen that the resources allocated to high-priority containers are actually the sum of the maximum resource parameter values ​​of all containers of high-priority services scheduled by the target server. Therefore, the cloud platform's super-allocation mechanism can also be understood as: the difference between the resources available to the target server and the sum of the maximum resource parameter values ​​of all containers of high-priority services scheduled by the target server is multiplied by N and allocated to all containers of low-priority services scheduled by the target server.

[0088] It should be noted that N > 1. The value of N can be set based on prior experience, manually, or determined based on the resource size of the server cluster and historical scheduling strategies; no specific restrictions are imposed here. Additionally, the target server schedules all containers of low-priority services, including containers of low-priority services already scheduled on the target server before the first request was received, and containers of the low-priority services indicated by the first request.

[0089] It is important to note that the allocatable resources of the target server are all the resources available for containers to use on the target server. This means that the allocatable resources of the target server are greater than or equal to the allocated resources of all containers scheduled on the target server.

[0090] It's understandable that the resources used by containers during service provision are not constant but dynamically change within the range of maximum resource parameter values. Therefore, in scenarios with multiple low-priority containers, the times at which these containers reach their maximum resource parameter values ​​may differ. In other words, at any given moment, the resources used by multiple low-priority containers may include those that have reached their maximum resource parameter values ​​and those that haven't. Therefore, over-allocating the remaining allocable resources of the target server to low-priority containers will not severely impact the services run by those containers. Furthermore, the service quality requirements of low-priority services are not high, so over-allocating the remaining allocable resources of the target server to low-priority containers will not significantly affect the user experience. In addition, the over-allocation mechanism can be seen as an extension of the target server's allocable resources, allowing the target server to create and schedule a specified number of low-priority containers.

[0091] In this embodiment, the remaining allocable resources of the target server are over-allocated N times to containers of all low-priority services scheduled by the target server, so that the target server can schedule a larger number of containers, thereby issuing a larger number of low-priority services and further improving the resource utilization of the target server.

[0092] In some optional implementations, the resources allocated to high-priority containers and low-priority containers in the server cluster can be dynamically adjusted. That is, after step 202 mentioned above, the cloud platform can monitor the resource usage of the server cluster and adjust the allocation of allocable resources of the server cluster based on the situation.

[0093] Specifically, the cloud platform obtains the actual resource utilization rate and resource utilization threshold of the server cluster, and adjusts x and / or N based on the actual resource utilization rate and resource utilization threshold.

[0094] Actual resource utilization rate = (Resources actually used by the server cluster / Allocable resources of the server cluster) × 100%

[0095] Actual resource utilization reflects the actual resource usage of a server cluster. The resource utilization threshold, on the other hand, represents the acceptable limit of resource utilization.

[0096] Understandably, adjusting x means adjusting the maximum resources that high-priority containers can use. The larger X is, the more high-priority services can be scheduled onto the server. The smaller X is, the fewer high-priority services can be scheduled onto the server.

[0097] Similarly, adjusting N means adjusting the resources allocated to low-priority containers. The larger N is, the more resources are over-allocated to low-priority containers, and the more low-priority services are scheduled to the server. The smaller N is, the fewer low-priority services are scheduled to the server.

[0098] Furthermore, resource utilization thresholds include a minimum resource utilization threshold and a maximum resource utilization threshold. The minimum resource utilization threshold represents the minimum acceptable resource utilization rate or slightly greater than the minimum, while the maximum resource utilization threshold represents the maximum acceptable resource utilization rate or slightly less than the maximum. The cloud platform adjusts x or N differently depending on the possible differences between the actual resource utilization rate and the resource utilization threshold. These differences are explained below:

[0099] In some optional implementations, if the actual resource utilization is less than or equal to the minimum resource utilization threshold, it indicates that the actual resource utilization is too low. The cloud platform adjusts the actual resource utilization by adjusting x and / or N. The cloud platform can increase N to schedule more low-priority services, and / or decrease x to reduce the allocable resources for high-priority services, thereby increasing the allocable resources for low-priority containers and improving resource utilization.

[0100] In some alternative implementations, if the actual resource utilization rate is greater than or equal to the highest resource utilization rate threshold, it indicates that the actual resource utilization rate is too high. The cloud platform can reduce N to decrease the allocable resources for low-priority services, and / or increase x to schedule more high-priority services, thereby avoiding the continued allocation of low-priority services and further improving resource utilization.

[0101] The actual resource utilization threshold being lower than the minimum resource utilization threshold can have several possibilities. It could mean that some servers in the server cluster have actual resource utilization rates lower than the minimum threshold, while others have resource utilization thresholds between the minimum and maximum thresholds. Alternatively, it could mean that the server cluster includes both servers with actual resource utilization rates lower than the minimum threshold and servers with resource utilization thresholds higher than the maximum threshold.

[0102] For example, suppose a server cluster includes server A and server B, each with 10 CPUs, and currently x is 80 and N is 3. Ten high-priority services are scheduled on these two servers. High-priority containers scheduled on server A use 8 CPUs, while those on server B use 2 CPUs. Therefore, for server A, low-priority containers can only use 2 CPUs, resulting in an over-utilization of 6 CPUs. For server B, low-priority containers can use 8 CPUs, resulting in an over-utilization of 24 CPUs. In this scenario, server A's actual resource utilization is too low, while server B's is too high, leading to an unbalanced load across the server cluster. The cloud platform then reduces x, say from 80 to 50. After rescheduling by the cloud platform, high-priority containers scheduled on both server A and server B each use 5 CPUs, achieving a more balanced load across the server cluster.

[0103] In some alternative implementations, if the actual resource utilization rate is greater than the minimum resource utilization threshold, and at least one container of high-priority services uses x% of the target server's idle resources, it indicates that under reasonable resource utilization conditions, x% of the target server's idle resources can just fully utilize the high-priority services. Therefore, the cloud platform can increase x to allow the target server to accommodate even more high-priority services.

[0104] Understandably, the ultimate goal of cloud platforms adjusting x and / or N is to adjust the resources allocated to high-priority and low-priority services on servers, thereby ensuring that the actual resource utilization of the servers is within a reasonable range. This reasonable range includes [the minimum resource utilization threshold and the maximum resource utilization threshold]. Multiple adjustments may be made before the actual resource utilization of the servers reaches a reasonable range.

[0105] In this embodiment of the application, the cloud platform increases x so that the server cluster can accommodate a larger number of high-priority containers, thus providing a larger number of high-priority services.

[0106] In summary, in the embodiments of this application, x and N are adjustable, which means that the resources allocated by the target server to high-priority containers and low-priority containers are adjustable. This allows for dynamic adjustment of the resources available to containers of different priorities based on actual conditions, resulting in higher resource utilization of the target server. Furthermore, the cloud platform adjusts x and / or N based on actual resource utilization and resource utilization thresholds, ensuring that the resources allocated by the server cluster to high-priority and low-priority containers better meet the needs of actual applications, thus improving the feasibility of the technical solution in this application.

[0107] In some alternative implementations, the first request may include, in addition to the maximum resource parameter value of the container, at least one minimum resource parameter value for at least one container. That is, for each container, the first request includes the container's maximum resource parameter value, minimum resource parameter value, and service level. The minimum resource parameter value represents the minimum amount of resources required by the container, or in other words, the minimum amount of resources the container can use.

[0108] Furthermore, the first request includes one or more pods, each pod comprising a set of containers. In addition to a service level and the maximum resource parameter values ​​for each container within the set of containers, as shown above, a pod also includes the minimum resource parameter values ​​for each container.

[0109] For example, suppose the target pod consists of two containers, container 1 and container 2. This target pod includes a service level, two maximum resource parameter values, and two minimum resource parameter values. The service level can be understood as the service level of container 1 and container 2, respectively. The two maximum resource parameter values ​​are the maximum resource parameter values ​​for container 1 and container 2, respectively. The two minimum resource parameter values ​​are the minimum resource parameter values ​​for container 1 and container 2, respectively.

[0110] In a scheme where the first request also includes a minimum resource parameter value, after receiving the first request, the cloud platform can modify the minimum resource parameter value based on the service level of each container. Specifically, the cloud platform will modify the minimum resource parameter value of at least one container serving high-priority services to the maximum resource parameter value of that container. Conversely, it will modify the minimum resource parameter value of at least one container serving low-priority services to a value significantly smaller than the maximum resource parameter value of that container.

[0111] For example, let `limits` represent the maximum resource parameter value and `requests` represent the minimum resource parameter value. Then, for high-priority containers, the cloud platform modifies `requests = limits`. For low-priority containers, the cloud platform modifies `requests << limits`. Optionally, for low-priority containers, `requests` can be set to 0.

[0112] In this embodiment, for containers of the modified high-priority service, the minimum resource parameter value is equal to the maximum resource parameter value, meaning that the container can use the maximum resource parameter value, thus ensuring the reliability of the high-priority service. For containers of the modified low-priority service, the minimum resource parameter value is much smaller than the maximum resource parameter value. Since the Kubernetes native scheduling policy limits the allocatable resources of the server cluster to be greater than or equal to the sum of the minimum resource parameter values ​​of all containers, this modification allows the server cluster to deploy a larger number of containers.

[0113] In summary, the first request may or may not include the minimum resource parameter value. For the former approach, the first request can be understood as including two resource parameters, and after receiving the first request, the cloud platform modifies the minimum resource parameter value based on the above description and the container's service level. For the latter approach, the first request can be understood as including only one resource parameter.

[0114] For example, in a scenario where the first request includes two resource parameters (i.e., the maximum resource parameter value and the minimum resource parameter value), the maximum resource parameter value can be represented by limits and the minimum resource parameter value can be represented by requests.

[0115] For example, in a scenario where the first request includes a resource parameter (i.e., the maximum resource parameter value), `size` can be used to represent the maximum resource parameter value. Therefore, for high-priority containers, including `size` in the first request is equivalent to modifying `requests` in the first request to have the same value as `limits`. For low-priority containers, including `size` in the first request is equivalent to modifying `requests` in the first request to be much smaller than `limits`.

[0116] In some alternative implementations, the first request may be an initial request or a modified request for at least one container. An initial request means that the services provided by the at least one container indicated by the first request are services that are being requested for the first time. A modified request means that among the services provided by the at least one container indicated by the first request, there are services identical to those in the past, and that each maximum resource parameter value indicated by the modified request is within a reasonable range.

[0117] This can be understood as the cloud platform setting up a service admission mechanism. For services requested for the first time, the target server is determined based on the resource definition (including the maximum resource parameter value, or both the maximum and minimum resource parameter values) and service level carried in the request. For services that have already been requested, the maximum resource parameter value in the resource definition is analyzed. For services with a maximum resource parameter value within a reasonable range, the target server is determined. Those with an unreasonable value are rejected from scheduling. A detailed explanation is provided below with reference to the diagram. Please refer to [link / reference]. Figure 3 , Figure 3 This is a flowchart illustrating the container scheduling method provided in an embodiment of this application.

[0118] 301. The terminal sends a second request to the cloud platform, the second request including at least one initial maximum resource parameter value for at least one container and at least one service level.

[0119] 302. The cloud platform sends a first message to the terminal, indicating that the creation of at least one container corresponding to the second request is refused.

[0120] The cloud platform analyzes the initial maximum resource parameter value of each container. If at least one container's service includes the same target service as a historical service, and the initial maximum resource parameter value of the target service included in the second request is not within the resource parameter range of the historical service, it indicates that the maximum resource parameter value of the target service in the second request is not within a reasonable range. Therefore, the cloud platform refuses to create a container for that service. The cloud platform sends a first message to the terminal, indicating that it refuses to create at least one container corresponding to the second request.

[0121] The resource parameter range of historical services refers to the range of resources used by historical services during runtime. It reflects the fluctuation range of resources used by historical services during operation.

[0122] For example, suppose the initial maximum resource parameter value of container A indicated by the second request is 1 CPU, and the service provided by container A is voice service. In the historical services provided by the cloud platform, the resource parameter range used by the voice service is [5, 10]. Then, the maximum resource parameter value included in the second request is too small, and the cloud platform refuses to schedule container A.

[0123] In this embodiment, the cloud platform will refuse to create the container corresponding to an unreasonable request, thereby ensuring that the creation of the container meets the needs of the actual application and improving the practicality of the technical solution of this application.

[0124] In some optional implementations, the cloud platform sends a first request to the terminal carrying a recommended maximum resource value for the target container, which is used to provide the target service. This allows the terminal to modify the maximum resource parameter value of the target container in the second request based on the recommended maximum resource value, thus obtaining the first request.

[0125] In some optional implementations, after step 302, the cloud platform executes step 303: sending a second message to the terminal, the second message including the maximum recommended value of the target container's resources. This causes the terminal to modify the maximum resource parameter value of the target container in the second request based on the maximum recommended value of the target container's resources, thus obtaining the first request.

[0126] Regardless of whether the maximum recommended resource value of the target container is carried in the first message or the second message, the terminal can obtain this parameter value, and the maximum recommended resource value of the target container is included in the resource parameter range of the historical service.

[0127] 304. The terminal sends a first request to the cloud platform. The maximum resource parameter value of the target container in the first request is the maximum recommended resource value.

[0128] After obtaining the maximum recommended resource value for the target container, the cloud platform sends a first request to the cloud platform. The maximum resource parameter value of the target container in the first request is also the maximum recommended resource value. This means that the maximum resource parameter value of each container in the first request is within its corresponding reasonable range.

[0129] 305. The cloud platform will schedule at least one container to the target server.

[0130] Step 305 and Figure 2 Step 202 in the illustrated embodiment is similar, as detailed above, and will not be repeated here.

[0131] In this embodiment, the cloud platform, while or after refusing to create at least one container corresponding to the second request, may send the maximum resource recommendation value of the target container. This allows the terminal to modify the initial maximum resource parameter value of the target container based on the maximum resource recommendation value, thus obtaining the first request. The cloud platform can send the maximum resource recommendation value of the target container in various ways, enriching the implementation methods and application scenarios of the technical solution in this application. Furthermore, carrying the maximum resource recommendation value of the target container in the first message can reduce the number of messages transmitted between the cloud platform and the terminal, thereby reducing the consumption of communication resources.

[0132] In some optional implementations, the cloud platform provided in this application embodiment can adopt... Figure 4 The structure shown. Please refer to [link / reference]. Figure 4 , Figure 4 This is a schematic diagram of the structure of the cloud platform provided in an embodiment of this application.

[0133] like Figure 4 As shown, the cloud platform 400 includes a service access module 401, a container modification module 402, a scheduling module 403, a data acquisition module 404, and a parameter recommendation module 405.

[0134] The service admission module 401 implements the aforementioned service admission mechanism. This includes analyzing the maximum resource parameter value of the container indicated in the container scheduling request. If the service provided by the container is the same as a historical service, and the maximum resource parameter value is not within the range of the historical service's resource parameters, then container creation is rejected, and a recommended maximum resource value is returned. It also estimates resource utilization based on historical data and the maximum resource parameter value. For container scheduling requests with estimated resource utilization lower than the minimum resource utilization threshold, container scheduling is rejected, and a recommended maximum resource parameter value is returned.

[0135] The container modification module 402, in a scheme where the container scheduling request includes both maximum and minimum resource parameter values, is used to modify the minimum resource parameter value according to different service levels. For containers providing high-priority services, the maximum and minimum resource parameter values ​​are made the same. For containers providing low-priority services, the minimum resource parameter value is made significantly smaller than the maximum resource parameter value.

[0136] The scheduling module 403 is used to set the resource scheduling policy to determine the target server for the scheduled containers. This includes setting a maximum of x% of the target server's idle resources for high-priority services. It may also include setting the difference between the sum of the target server's idle resources and the maximum resource parameter values ​​of high-priority services, multiplied by N, to be allocated to low-priority containers.

[0137] The data acquisition module 404 is used to collect historical data, current network data, resource utilization thresholds, etc. Historical data includes the maximum resource parameter values ​​of historical services and the historical resource utilization of at least one server managed by the cloud platform. Current network data includes the current resource utilization of servers. Resource utilization thresholds include the minimum resource utilization threshold and the maximum resource utilization threshold. The data collected by the data acquisition module 404 can provide a reference for the service admission module 401 to determine whether to reject container scheduling requests, and can also provide a reference for the x and N values ​​output by the parameter recommendation module 405.

[0138] The parameter recommendation module 405 is used to adjust the values ​​of x and / or N based on the actual resource utilization rate and the resource utilization threshold, and to feed back to the scheduling module 403 so that the scheduling module 403 can adjust the scheduling strategy.

[0139] It should be noted that the service admission module 401 and the container modification module 402 are optional modules. In a cloud platform including the service admission module 401, the cloud platform has the aforementioned service admission mechanism. Based on this module, the cloud platform analyzes the maximum resource parameter value of each requested container. In a cloud platform without the service admission module 401, after obtaining the container scheduling request, the cloud platform directly schedules the container to the server. In a cloud platform including the container modification module 402, the container scheduling request includes both the maximum and minimum resource parameter values. In a cloud platform without the container modification module 402, the container scheduling request does not include the minimum resource parameter value; in other words, the container scheduling request includes only one resource parameter.

[0140] in addition, Figure 4 The container scheduling request mentioned in the illustrated embodiment may be the first request or the second request in the foregoing embodiments.

[0141] based on Figure 4 The cloud platform shown in this application provides an example of a container scheduling method. Figure 5 As shown, please refer to Figure 5 , Figure 5 This is a flowchart illustrating the container scheduling method provided in an embodiment of this application.

[0142] like Figure 5 As shown, service operators or users interact with the terminal, triggering the terminal to send a container scheduling request to the cloud platform. This process can also be understood as distributing containers to the Kubernetes cluster managed by the cloud platform, or requesting the cloud platform to distribute services based on the Kubernetes system. The former scenario will be used as an example in the following explanation.

[0143] The kube-APIserver component in the cloud platform receives container scheduling requests and invokes the webhook of the service admission module to analyze the maximum resource parameter values ​​included in the container scheduling request. If the service targeted by the container scheduling request is being deployed for the first time, the service admission module directly approves the container scheduling request. If the service targeted by the container scheduling request includes the same target service as a historical service, the service admission module obtains the historical service utilization and analyzes whether the maximum resource parameter value of the target service is reasonable. If reasonable, the container scheduling request is approved; if unreasonable, the container scheduling request is rejected, including refusing to deploy containers for the target service. The service admission module also returns a recommended maximum resource value. The terminal modifies the maximum resource parameter value of the target service in the container scheduling request based on the recommended maximum resource value, obtaining a modified container scheduling request. The modified container scheduling request is then sent to the cloud platform again. The service admission module analyzes again until deployment is allowed. In the container scheduling requests that are allowed to be deployed, the maximum resource parameter value of each container is within a reasonable range.

[0144] After a container scheduling request is approved, the kube-APIserver component can also invoke the webhook of the container modification module. This module modifies the resource definitions in the container scheduling request based on the service level included in the request. Specifically, it modifies the minimum resource parameter values ​​of high-priority containers to be the same as their maximum values, and modifies the minimum resource parameter values ​​of low-priority containers to be significantly smaller than their maximum values. The kube-APIserver component stores the modified resource definitions (i.e., the information about the containers to be scheduled) in etcd.

[0145] The parameter recommendation module obtains resource utilization information from the data acquisition module, including the actual resource utilization of the server and the resource utilization threshold, and determines the values ​​of x and N. It then sends the values ​​of x and N to the scheduling module.

[0146] The scheduling module obtains the container information to be scheduled, as well as the values ​​of x and N, and selects a target server from at least one server managed by the cloud platform to schedule the container. It then sends the container scheduling information to the kube-APIserver component. The kube-APIserver component accesses etcd to store the container scheduling information. The container scheduling information includes the scheduling policy corresponding to the current container scheduling request.

[0147] The kubelet on the target server retrieves information about containers to be scheduled from etcd through the kube-APIserver component and then schedules the containers on the target server. The scheduled containers are... Figure 5 In the illustrated embodiment, the modified container scheduling request indicates the container.

[0148] The following describes the relevant equipment provided in the embodiments of this application.

[0149] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a cloud platform provided in an embodiment of this application. In this embodiment, the cloud platform is used to manage a server cluster, and the cloud platform manages the containers scheduled on the server cluster based on a container management system. Figure 6 As shown, the cloud platform 600 includes a transceiver unit 601 and a processing unit 602.

[0150] In some optional implementations, the transceiver unit 601 is configured to obtain a first request, the first request including at least one maximum resource parameter value of at least one container and at least one service level corresponding to at least one container, the at least one service level including high priority service.

[0151] The processing unit 602 is configured to schedule at least one container to a target server, which is contained in a server cluster, based on at least one maximum resource parameter value and at least one service level, and to allocate at most some or all of the resources available on the target server to containers of all high-priority services scheduled on the target server.

[0152] In some alternative implementations, at least one service level also includes low-priority services. The difference between the resources that the target server can allocate and the sum of the maximum resource parameter values ​​of all containers of high-priority services scheduled by the target server, multiplied by N, is over-allocated to all containers of low-priority services scheduled by the target server, where N > 1.

[0153] In some alternative implementations, part or all of the resources available for allocation on the target server is x% of the resources available for allocation on the target server, where x is (0, 100).

[0154] The transceiver unit 601 is also used to obtain the actual resource utilization rate and resource utilization threshold of the server cluster.

[0155] The processing unit 602 is also configured to adjust at least one of x or N based on the actual resource utilization rate and the resource utilization rate threshold.

[0156] In some alternative implementations, the resource utilization threshold includes a minimum resource utilization threshold and a maximum resource utilization threshold.

[0157] The processing unit 602 is specifically configured to: increase N and / or decrease x if the actual resource utilization rate is less than or equal to the minimum resource utilization rate threshold; and decrease N and / or increase x if the actual resource utilization rate is greater than or equal to the maximum resource utilization rate threshold.

[0158] In some alternative implementations, the resource utilization threshold includes a minimum resource utilization threshold and a maximum resource utilization threshold.

[0159] The processing unit 602 is specifically used to increase x if the actual resource utilization rate is greater than the minimum resource utilization rate threshold and the resources used by the containers of all high-priority services called by the server cluster are x% of the server's allocable resources.

[0160] In some alternative implementations, the first request may also include at least one minimum resource parameter value for at least one container.

[0161] The processing unit 602 is further configured to: modify the minimum resource parameter value of the container providing high-priority services in at least one container to the maximum resource parameter value of the container providing high-priority services; and modify the minimum resource parameter value of the container providing low-priority services in at least one container to a value much smaller than the maximum resource parameter value of the container providing low-priority services.

[0162] In some optional implementations, the transceiver unit 601 is further configured to: obtain a second request, the second request including at least one initial maximum resource parameter value of at least one container and a service level of at least one container. If the service of at least one container includes the same target service as the historical service, and the initial maximum resource parameter value of the target service included in the second request is not included in the resource parameter range of the historical service, then a first message is sent, the first message indicating that the creation of at least one container corresponding to the second request is refused.

[0163] In some optional implementations, the first message also includes a maximum recommended resource value for the target container, which is used to provide the target service. The maximum resource parameter value of the target container in the first request is the maximum recommended resource value.

[0164] In some optional implementations, the transceiver unit 601 is further configured to: send a second message, the second message including the maximum recommended resource value of the target container, the target container being used to provide the target service. The maximum resource parameter value of the target container in the first request is the maximum recommended resource value.

[0165] Both the transceiver unit 601 and the processing unit 602 can be implemented in software or in hardware. For example, the implementation of the processing unit 602 will be described below. Similarly, the implementation of the transceiver unit 601 can be referenced to that of the processing unit 602.

[0166] As an example of a software functional unit, processing unit 602 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the aforementioned computing instance may be one or more. For example, processing unit 602 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0167] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0168] As an example of a hardware functional unit, processing unit 602 may include at least one computing device, such as a server. Alternatively, processing unit 602 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0169] The processing unit 602 includes multiple computing devices that can be distributed in the same region or in different regions. Similarly, the processing unit 602 can be distributed within the same Availability Zone (AZ) or in different AZs. Likewise, the processing unit 602 can be distributed within the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0170] It should be noted that the data cloud platform 600 achieves all its functions by implementing different steps in the container scheduling method through the transceiver unit 601 and the processing unit 602. The cloud platform 600 is used for the aforementioned... Figures 1 to 5 The operations performed by the cloud platform in the illustrated embodiment are to implement the container scheduling method provided in this application embodiment, and will not be described in detail here.

[0171] Please see Figure 7 , Figure 7This is a schematic diagram of a computing device provided in an embodiment of this application. The computing device 700 includes a processor 701, a communication interface 702, a bus 703, and a memory 704. The processor 701, the communication interface 702, and the memory 704 communicate with each other via the bus 703. In practical applications, communication can also be achieved through other means such as wireless transmission; the specific method is not limited here.

[0172] The computing device 700 may be a server or a terminal device. It should be understood that this application does not limit the number of processors and memory in the computing device 700.

[0173] Processor 701 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0174] The communication interface 702 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 700 and other devices or communication networks.

[0175] The 703 bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 7 The bus 703 is represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 703 may include a path for transmitting information between various components of the computing device 700 (e.g., memory 704, processor 701, communication interface 702).

[0176] Memory 704 may include volatile memory, such as random access memory (RAM). Memory 704 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0177] The memory 704 stores executable program code, and the processor 701 executes the executable program code to implement the functions of the aforementioned transceiver unit 601 and processing unit 602, thereby implementing the container scheduling method. That is, the memory 704 stores instructions for executing the container scheduling method.

[0178] This application also provides a computing device cluster, which includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some optional embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0179] Please see Figure 8 and Figure 9 , Figure 8 and Figure 9 These are all schematic diagrams of the computing device clusters provided in the embodiments of this application.

[0180] like Figure 8 As shown, the computing device cluster includes at least one computing device 700. The memory 704 in one or more computing devices 700 in the computing device cluster may store the same instructions for executing the container scheduling method provided in the embodiments of this application.

[0181] In some possible implementations, the memory 704 of one or more computing devices 700 in the computing device cluster may also store partial instructions for executing the container scheduling method. In other words, a combination of one or more computing devices 704 can jointly execute the instructions for executing the container scheduling method.

[0182] It should be noted that the memory 704 in different computing devices 700 within the computing device cluster can store different instructions, each used to execute a portion of the cloud platform's functions. That is, the instructions stored in the memory 704 of different computing devices 700 can implement the functions of one or more units among the transceiver unit 601 and the processing unit 602.

[0183] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 9 One possible implementation is shown. For example... Figure 9As shown, two computing devices 700A and 700B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this possible implementation, the memory 704 in computing device 700A stores instructions for performing the functions of transceiver unit 601. Meanwhile, the memory 704 in computing device 700B stores instructions for performing the functions of processing unit 602.

[0184] Figure 9 The connection method between the computing device clusters shown can be based on the container scheduling method provided in this application, which separates the processing operation from the operation other than the processing operation. That is, it is considered that the function of the transceiver unit 601 is executed by the computing device 700A, and the function of the processing unit 602 is executed by the computing device 700B.

[0185] It should be understood that Figure 9 The functions of the computing device 700A shown can also be performed by multiple computing devices 700. Similarly, the functions of the computing device 700B can also be performed by multiple computing devices 700.

[0186] This application also provides another computing device cluster. The connection relationships between the computing devices in this computing device cluster can be similarly referred to... Figure 8 and Figure 9 The connection method of the computing device cluster will not be described in detail here.

[0187] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computer device, the at least one computer device performs the container scheduling method described above.

[0188] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the container scheduling method described above.

[0189] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0190] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.

Claims

1. A container dispatching method characterized by comprising: The method is applied to a cloud platform for managing a server cluster, and comprises: obtaining a first request, the first request comprising at least one maximum resource parameter value of at least one container and at least one service level corresponding to the at least one container, the at least one service level comprising a high-priority service; scheduling the at least one container to a target server according to the at least one maximum resource parameter value and the at least one service level, the target server being included in the server cluster, and at most a part or all of allocable resources of the target server being allocated to containers of all high-priority services scheduled by the target server.

2. The method of claim 1, wherein, The at least one service level further comprises a low-priority service. A difference between the allocable resources of the target server and a sum of maximum resource parameter values of all high-priority service containers scheduled by the target server is N times of an allocation to all low-priority service containers scheduled by the target server, N>1.

3. The method of claim 2, wherein, The part or all of the allocable resources of the target server is x% of the allocable resources of the target server, x being (0, 100]; the method further comprises: obtaining an actual resource utilization rate of the server cluster and a resource utilization rate threshold value; adjusting at least one of the x or the N according to the actual resource utilization rate and the resource utilization rate threshold value.

4. The method of claim 3, wherein, The resource utilization rate threshold value comprises a resource utilization rate minimum threshold value and a resource utilization rate maximum threshold value; adjusting at least one of the x or the N according to the actual resource utilization rate and the resource utilization rate threshold value comprises: if the actual resource utilization rate is less than or equal to the resource utilization rate minimum threshold value, increasing the N and / or decreasing the x; if the actual resource utilization rate is greater than or equal to the resource utilization rate maximum threshold value, decreasing the N and / or increasing the x.

5. The method according to claim 3 or 4, characterized in that, The resource utilization rate threshold value comprises a resource utilization rate minimum threshold value and a resource utilization rate maximum threshold value; adjusting at least one of the x or the N according to the actual resource utilization rate and the resource utilization rate threshold value comprises: if the actual resource utilization rate is greater than the resource utilization rate minimum threshold value and resources used by all high-priority service containers invoked by the server cluster are x% of allocable resources of the server cluster, increasing the x.

6. The method according to any one of claims 1 to 5, characterized in that, The first request further comprises at least one minimum resource parameter value of the at least one container; after the obtaining of the first request, the method further comprises: modifying the minimum resource parameter value of a high-priority service container in the at least one container to the maximum resource parameter value of the high-priority service container; modifying the minimum resource parameter value of a low-priority service container in the at least one container to be much smaller than the maximum resource parameter value of the low-priority service container.

7. The method according to any one of claims 1 to 6, characterized in that, before the obtaining of the first request, the method further comprises: obtaining a second request, the second request comprising at least one initial maximum resource parameter value of the at least one container and the at least one service level; If the service of the at least one container comprises a same target service as a historical service, and an initial maximum resource parameter value of the target service comprised in the second request is not included in a resource parameter range of the historical service, a first message is sent, the first message indicating rejection of creation of the at least one container corresponding to the second request.

8. The method of claim 7, wherein, The first message further comprises a maximum resource recommendation value of a target container for providing the target service. The maximum resource parameter value of the target container in the first request is the maximum resource recommendation value.

9. The method of claim 7, wherein, After the sending of the first message, the method further comprises: sending a second message, the second message comprising a maximum resource recommendation value of a target container for providing the target service; The maximum resource parameter value of the target container in the first request is the maximum resource recommendation value.

10. A cloud platform, characterized by The cloud platform is used for managing a server cluster, and the cloud platform comprises: a transceiving unit configured to obtain a first request, the first request comprising at least one maximum resource parameter value of at least one container and at least one service level corresponding to the at least one container, the at least one service level comprising a high-priority service; a processing unit configured to schedule the at least one container to a target server according to the at least one maximum resource parameter value and the at least one service level, the target server being included in the server cluster, and at most a part or all of allocable resources of the target server being allocated for use by containers of all high-priority services scheduled to the target server.

11. The cloud platform of claim 10, wherein, The at least one service level further comprises a low-priority service. A difference between the allocable resources of the target server and a sum of maximum resource parameter values of the containers of all high-priority services scheduled to the target server is N times of an over-allocated amount for use by containers of all low-priority services scheduled to the target server, N>1.

12. The cloud platform of claim 11, wherein, The part or all of the allocable resources of the target server is x% of the allocable resources of the target server, x being (0, 100]; The transceiving unit is further configured to obtain an actual resource utilization rate of the server cluster and a resource utilization rate threshold value; The processing unit is further configured to adjust at least one of the x or the N according to the actual resource utilization rate and the resource utilization rate threshold value.

13. The cloud platform of claim 12, wherein, The resource utilization rate threshold value comprises a lowest resource utilization rate threshold value and a highest resource utilization rate threshold value; The processing unit is specifically configured to: if the actual resource utilization rate is less than or equal to the lowest resource utilization rate threshold value, increase the N and / or decrease the x; and / or if the actual resource utilization rate is greater than or equal to the highest resource utilization rate threshold value, decrease the N and / or increase the x.

14. The cloud platform of claim 12 or 13, wherein, The resource utilization rate threshold value comprises a lowest resource utilization rate threshold value and a highest resource utilization rate threshold value; The processing unit is specifically configured to, if the actual resource utilization rate is greater than the lowest resource utilization rate threshold value and resources used by all high-priority service containers invoked by the server cluster are x% of allocable resources of the server cluster, increase the x.

15. The cloud platform of any one of claims 10 to 14, wherein, The first request further comprises at least one minimum resource parameter value of the at least one container; The processing unit is further configured to: modify the minimum resource parameter value of a container of high priority service in the at least one container to a maximum resource parameter value of the container of high priority service; modify the minimum resource parameter value of a container of low priority service in the at least one container to a value much less than a maximum resource parameter value of the container of low priority service.

16. The cloud platform of any one of claims 10 to 15, wherein, The transceiving unit is further configured to: obtain a second request, the second request comprising at least one initial maximum resource parameter value of the at least one container and at least one service level; if the service of the at least one container comprises a target service same as a historical service, and the initial maximum resource parameter value of the target service comprised in the second request is not included in a resource parameter range of the historical service, send a first message, the first message indicating rejection of creation of the at least one container corresponding to the second request.

17. The cloud platform of claim 16, wherein, The first message further comprises a maximum resource recommendation value of a target container, the target container being used to provide the target service. The maximum resource parameter value of the target container in the first request is the maximum resource recommendation value.

18. The cloud platform of claim 16, wherein, The transceiving unit is further configured to: send a second message, the second message comprising a maximum resource recommendation value of a target container, the target container being used to provide the target service; The maximum resource parameter value of the target container in the first request is the maximum resource recommendation value.

19. A cluster of computing devices, characterized in that, The at least one computing device comprises a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 9.

20. A computer program product comprising instructions, characterized in that, When the instructions are executed by the computing device cluster, the computing device cluster is caused to execute the method according to any one of claims 1 to 9.

21. A computer-readable storage medium, characterized in that, The computer readable storage medium comprises computer program instructions, when the computer program instructions are executed by the computing device cluster, the computing device cluster is caused to execute the method according to any one of claims 1 to 9.

Images