Server-free function elastic scheduling method and system based on heterogeneous container combination

Abstract

The invention relates to a server-free function elastic scheduling method and system based on heterogeneous container combination. The method comprises the following steps: analyzing and determining the maximum request concurrency processed by containers under different resource specifications; collecting container attribute information of each function; determining a function deployment plan based on the change of the resource elastic demand at different moments and different functions, the maximum request concurrency and the container attribute information; and configuring the container in an in-situ upgrading manner based on the function deployment plan, or configuring a non-upgradable container in a manner of creating a new container and / or destroying an old container. According to the method, the computing resources required by the application are provided in a mode of combining the containers with heterogeneity of resource specifications. And by combining the advantages of large and small containers with different resource specifications, a higher cluster resource utilization rate is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of resource elastic scheduling, and in particular to a serverless function elastic scheduling method and system based on heterogeneous container combination. Background Art

[0002] With the rapid development of cloud computing and serverless computing, cloud users have achieved more fine-grained use of cloud resources and on-demand payment through services such as function computing. This model significantly improves user experience and simplifies the user's operation and maintenance burden, but it also brings unprecedented resource management challenges to cloud service providers. Cloud service providers need to efficiently manage computing resources on many server nodes and accurately allocate and schedule resources for containers of different functions. This requires cloud service providers to not only accurately capture the resource requirements of functions, but also find the best balance between performance and cost.

[0003] In the serverless computing model, functions are usually encapsulated in the form of containers. This encapsulation improves the flexibility of deployment and management, but the existing function resource scheduling methods have exposed many shortcomings in high-concurrency and large-scale task processing. Serverless platforms based on Kubernetes usually adopt elastic expansion based on passive strategies, which often leads to cold start overhead and performance interference of containers, seriously affecting the full utilization of node resources, resulting in performance bottlenecks of resource expansion and reduced resource utilization efficiency when processing rapidly changing workloads.

[0004] For example, take the video transcoding function as an example. In a serverless platform, when a user uploads a video, the function is triggered to perform transcoding. At a certain moment, a large number of users suddenly upload videos at the same time. According to the Kubernetes passive resource elasticity strategy, the system monitors a series of indicators, such as CPU utilization, memory usage, network traffic, etc., to detect the load of the container. When these monitoring indicators exceed the preset threshold, it indicates that the system load has reached the peak and resources need to be expanded to meet user needs. Based on this passive strategy, the system automatically triggers the dynamic expansion of the number of containers to cope with this sudden increase in load. Due to the long cold start time of the container, the system needs a certain amount of time to initialize these new containers during the expansion process, which may cause response delays or unstable services during peak periods. As the peak period ends, the number of user requests to upload videos gradually decreases. According to the passive strategy, the system will automatically destroy some containers that are no longer needed after a delay to save resources. However, since the container destruction process may take a certain amount of time and the destroyed resources may not be immediately available for other tasks, this may lead to resource waste and degradation of system performance.

[0005] For example, the patent document with publication number CN110837408A discloses a high-performance serverless computing method and system based on resource caching, which includes a client, a control node, a computing node, and a software package repository; wherein the client is used to initiate a call request to request to call the serverless computing platform; the control node is responsible for receiving the call request in the serverless computing, triggering the call, scheduling the container, and electing the master node in the serverless computing platform, and when the scheduler schedules the serverless processing program, it queries the software package registry and schedules the container used to execute the serverless processing program to the appropriate node; the container cache controller of the control node is responsible for collecting the execution information of the container on the computing node and the status information of the system, and adjusting the container cache time according to the collected information, and the software package registry of the control node is responsible for storing the mapping information of function-software package and software package-computing node. However, this patent can only adjust the container cache time, and cannot upgrade, replace or delete the container itself in situ.

[0006] Therefore, how to provide a more efficient and intelligent function resource scheduling method to flexibly respond to complex and changing resource demands, improve resource utilization and resource elasticity response speed, and at the same time effectively reduce operating costs is a problem that needs to be further solved.

[0007] In addition, on the one hand, there are differences in understanding among those skilled in the art; on the other hand, the applicant studied a large number of documents and patents when making the present invention, but due to space limitations, not all details and contents are listed in detail. However, this does not mean that the present invention does not have the characteristics of these prior arts. On the contrary, the present invention already has all the characteristics of the prior art, and the applicant reserves the right to add relevant prior art to the background technology. Summary of the invention

[0008] In the serverless computing model, functions are usually encapsulated in the form of containers. This encapsulation improves the flexibility of deployment and management, but the existing function resource scheduling methods have exposed many shortcomings in high-concurrency and large-scale task processing. Serverless platforms based on Kubernetes usually adopt elastic expansion based on passive strategies, which often leads to cold start overhead and performance interference of containers, seriously affecting the full utilization of node resources, resulting in performance bottlenecks of resource expansion and reduced resource utilization efficiency when processing rapidly changing workloads.

[0009] In order to alleviate the response delay caused by the cold start problem, the prior art has already presented a technical solution that reduces the cold start frequency by sensing the container life cycle and predicting the arrival of tasks in the future. For example, the patent document with publication number CN117331648A discloses a task scheduling system and method for alleviating the cold start problem of serverless computing, which at least includes a container state tracking module, a request arrival prediction module and a request scheduling module. The container state tracking module is implemented by deploying a container state tracker in the master node of the cluster, and tracks the container state according to the container state information and scheduling decision on the working node; the request arrival prediction module is based on the historical request data in the system, and obtains the arrival of tasks in the future through a time series prediction model, and controls the pre-creation or deletion of containers; the request scheduling module reasonably schedules the newly arrived requests and controls the creation and deletion of containers according to the container state information and request arrival information. This technical solution comprehensively considers the life cycle status of the container, the future arrival of the task request and predicts it, and assigns an optimal working node to the task for processing, thereby minimizing the overall average response time of the task. However, in a serverless computing platform, usually a function instance can carry multiple concurrent requests, and redundant requests can be queued. Usually, functions need to be pre-configured, including setting the upper limit of concurrent requests that can be processed simultaneously and the request queuing time. Once these configurations are set, they cannot be changed during operation, which limits the adaptive adjustment of container status information. Under different resource restriction environments, the concurrency that a single function instance can carry is different, and the user's latency requirements for different functions may also be different; at the same time, the resources allocated to a function instance are limited. The higher the instance load, the more serious the resource contention phenomenon will be, and the request latency will be extended, resulting in the inability to meet the service quality. Therefore, the real-time changes in task requests will have a huge impact on the allocation of resources. This real-time change is difficult to predict only through the preset model, so it may cause the service quality to be seriously affected. In addition, this type of active resource allocation method that determines the configuration in time or in advance relies on the machine learning model to configure the resources, and the active control relies on the prediction accuracy of the machine learning model, which is obviously different from the technical solution of the present invention that optimizes resource configuration and container deployment strategy in real time through resource specification analysis and container attribute information, which can significantly reduce the impact of the prediction accuracy of the machine learning model on the container deployment strategy.

[0010] In view of the deficiencies of the prior art, the present invention provides a serverless function elastic scheduling method based on heterogeneous container combination from a first aspect, the method comprising:

[0011] S1: Analyze and determine the maximum concurrent requests that can be processed by containers under different resource specifications. Through this analysis, the maximum concurrent requests that can be processed by containers under various resource specifications can be determined, thereby providing data support for subsequent resource configuration.

[0012] S2: Collect container attribute information of each function.

[0013] S3: Determines the function deployment plan based on the changes in resource elasticity requirements at different times and for different functions, the maximum request concurrency, and container attribute information; this decision-making process considers various possible resource combinations of containers with different resource specifications to achieve the best resource elasticity performance and cluster resource utilization.

[0014] S4: Configure containers in an in-place upgrade manner based on the function deployment plan, or configure non-upgradeable containers by creating new containers and / or destroying old containers. This configuration method ensures that the system remains efficient and stable when handling load changes.

[0015] Unlike the prior art, the present invention can determine the function deployment plan based on multiple factors such as the changes in real-time resource elasticity requirements at different times and for different functions, the maximum concurrent request volume, and container attribute information, and can adjust the configuration of different types of containers according to the determined function deployment plan. Based on the above-mentioned distinguishing technical features, the problems to be solved by the present invention may include: how to improve the resource scheduling efficiency and response speed in a serverless computing environment to reduce resource waste and operating costs. Specifically, the resource requirements of a serverless computing environment are dynamically changing. The present invention monitors and analyzes the resource requirements of different functions in real time, dynamically adjusts the resource configuration, and ensures that the resource configuration always matches the actual requirements to achieve efficient use of resources. Traditional container deployment decisions often ignore the speed of container creation. The present invention innovatively considers the key indicator of server node container creation speed into the container placement decision. The fast startup capability of the container is crucial to reducing the delay of request processing, especially in the face of burst traffic, and can quickly expand resources to meet demand; at the same time, a deployment cost evaluation algorithm is designed to evaluate the cost-effectiveness of different container deployment schemes. This evaluation not only considers short-term resource costs, but also includes maintenance and expansion costs in long-term operations, ensuring the maximization of cost-effectiveness; in order to quickly find the optimal solution among many possible deployment schemes, the present invention uses a heuristic algorithm to develop the best container specification selection and combined deployment scheme. By continuously updating the function deployment plan, optimizing container deployment, determining whether a new container needs to be created, determining containers suitable for in-situ resource upgrade and expansion, and managing container destruction. In a cluster, fragmented resources may be generated due to the resource requirements and life cycles of different containers. Throughout the process, the present invention focuses on improving the expansion speed of function resources, and is also committed to balancing the utilization of fragmented resources within the cluster, avoiding idleness and waste of resources, thereby reducing the cost of the cloud platform.

[0016] According to a preferred embodiment, the method for collecting container attribute information of each function includes: collecting resource specification information and / or location information of the container; monitoring the operating status of the container and / or the available resource status of each server node. Unlike the prior art, the present invention can conduct in-depth collection and analysis of container attribute information to optimize resource allocation strategies according to different containers. Based on the above-mentioned distinguishing technical features, the problems to be solved by the present invention may include: how to improve the accuracy of resource allocation in a serverless computing environment. Specifically, the present invention not only covers the resource specifications and location information of the container, but also includes real-time monitoring of the operating status of the container and continuous evaluation of the available resources of the server node. This comprehensive data collection provides a solid foundation for resource allocation, enabling the system to dynamically adjust resources according to actual needs, thereby improving overall operating efficiency and reducing unnecessary waste of resources, that is, by collecting container attribute information of each function, detailed data can be provided for resource allocation.

[0017] According to a preferred embodiment, the method for determining a function deployment plan includes: calculating the deployment cost and concurrency of each container specification on different server nodes and under different container concurrency conditions; selecting the container specification and server node combination with the minimum deployment overhead per unit concurrency according to the deployment cost and concurrency of the container specification. Unlike the prior art, the present invention selects the most cost-effective container specification and node combination by evaluating the cost of various container specifications on different server nodes and the ability to handle concurrent requests. Based on the above-mentioned distinguishing technical features, the problems to be solved by the present invention may include: how to reduce the deployment and operation and maintenance costs in a serverless computing environment while ensuring the quality of service. Specifically, the present invention implements a dynamic and adaptive resource allocation mechanism by comprehensively considering the deployment cost and concurrency of the container specifications, as well as the resource utilization of the server nodes. Through these two steps, the present invention can formulate a final optimized container deployment plan to minimize costs.

[0018] According to a preferred embodiment, the deployment cost includes expansion cost and resource cost; the method for calculating the deployment cost includes: evaluating the time consumption data generated by container changes in the container deployment plan to determine the expansion cost; evaluating the resource cost of all containers in the container deployment plan.

[0019] Unlike the prior art, the deployment cost of the present invention consists of two parts: expansion cost and resource cost, wherein the expansion cost is calculated based on the time required for container changes, while the resource cost is evaluated based on the use of resources in the container deployment scheme. Based on the above-mentioned distinguishing technical features, the problems to be solved by the present invention may include: how to ensure the system response speed while reducing the deployment cost. Specifically, as mentioned above, the prior art usually achieves resource expansion by recreating or adding new container instances. This method may result in a longer startup time because operations such as pulling images and initializing container environments are required, thereby increasing the system response delay. At the same time, the prior art does not take into account the expansion cost in the process of deciding the placement of containers. Therefore, the container deployment plan of the prior art often has an imbalance in the creation of containers on different server nodes, resulting in performance bottlenecks. In contrast, the present invention takes into account the calculation of the expansion cost, not only calculates the time consumption caused by the container change to determine the expansion cost, but also evaluates the resource cost of all containers in the container deployment scheme, dynamically adjusts the resource allocation, ensures that it matches the node resource utilization, and makes the container deployment plan more intelligent and efficient. The present invention also dynamically adjusts the container resource cost to keep it consistent with the node resource utilization. This method of comprehensively considering time and resource costs enables the present invention to minimize costs in container deployment while improving the response speed and overall performance of the system. Through the above-mentioned setting, the present invention can effectively solve the startup delay and performance bottleneck problems existing in the prior art, and provide a more advanced and economical solution for resource management and scheduling in a serverless computing environment.

[0020] According to a preferred embodiment, the method for determining a function deployment plan also includes: initializing the function deployment plan and the current total concurrency, selecting the most cost-effective container specification and server node based on the target concurrency and the calculation results of the deployment cost per unit concurrency of each server node; updating the container deployment plan and node resources according to the selection results; and returning the final container deployment plan when the current total concurrency reaches or exceeds the target concurrency.

[0021] Unlike the prior art, the present invention first sets the initial deployment and evaluates the concurrency, then selects the most cost-effective container and node, then updates the deployment and resources, and confirms the final deployment plan when the concurrency reaches the standard. Based on the above-mentioned distinguishing technical features, the problems to be solved by the present invention may include: how to improve the utilization efficiency of resources while reducing the deployment cost. Specifically, the prior art generally adopts a static resource cost calculation method when evaluating container deployment schemes. This method assumes that no matter how the actual resource usage of the server node changes, the resource cost required by the container is always fixed. Its main disadvantage is that it fails to fully consider the actual impact of the dynamic change of the resource utilization of the server node on the resource cost of the container. Specifically, when the resource utilization of a server node is high, the calculation according to the fixed cost may lead to over-allocation of resources, resulting in unnecessary waste of resources. In this case, if the resource cost can be adjusted according to the actual resource usage, resources may be used more effectively and waste may be reduced. On the contrary, on nodes with low resource utilization, the fixed cost calculation method may not provide enough resources, resulting in insufficient resource supply, affecting the stability and performance of the service. Therefore, this method has obvious limitations in resource management and scheduling, and cannot flexibly respond to changes in resource requirements of different nodes, and cannot achieve optimal resource allocation, which not only affects the efficiency of the serverless computing environment, but also may lead to unnecessary cost increases. In the steps of the present invention, selecting the minimum container specification and server node combination means selecting the container specification and server node combination with the lowest deployment cost to ensure the maximization of resource utilization efficiency and cost-effectiveness.

[0022] According to a preferred embodiment, a method for configuring a container in an in-place upgrade manner based on a function deployment plan includes: directly and dynamically changing the resource configuration and the concurrent request processing of the container without recreating the container to achieve rapid resource elastic response.

[0023] Unlike the prior art, the container of the present invention dynamically adjusts resource configuration and concurrent processing capabilities in situ without re-creation. Based on the above-mentioned distinguishing technical features, the problems to be solved by the present invention may include: how to improve the response speed of container resource allocation. Specifically, in a serverless computing environment, rapid response and efficient utilization of resources are key, and upgrading container resources in situ is more efficient than creating a new container. The present invention can modify the resource allocation of a container without restarting the container. Specifically, the present invention can dynamically adjust the resource configuration of the container such as CPU, memory and storage without restarting the container. This in-situ upgrade mechanism not only reduces the delay caused by restarting the container, but also avoids the additional time and resource consumption required to redeploy the container. In this way, the system can quickly respond to changes in resource requirements, whether it is necessary to process requests with higher concurrency or to add more computing resources to existing containers. In addition, the present invention also considers how to balance resource allocation and request delay performance when configuring large containers with higher concurrency. By intelligently adjusting resource configuration, the system can achieve faster response time and higher processing power without sacrificing user experience. This method not only improves the response flexibility of resources, but also ensures that the system can still maintain stable and efficient operation under high load conditions. In practical applications, this in-place upgrade strategy can significantly improve the scalability and reliability of the serverless computing environment, allowing the system to flexibly adjust resource configuration and quickly expand service capabilities while maintaining cost-effectiveness in the face of changing business needs. Therefore, the present invention can increase the resource allocation of existing containers while configuring larger containers with higher concurrency, achieve rapid resource expansion, and ensure satisfactory request latency performance, thereby improving resource response flexibility.

[0024] According to a preferred embodiment, a method for configuring a non-upgradeable container by creating a new container and / or destroying an old container includes: for a container that needs to upgrade resource configuration, switching to a new container configuration smoothly by starting a new container instance and gradually migrating traffic; for a container that cannot directly upgrade resource configuration, destroying the old container, and creating a new container instance on an appropriate server node to meet the updated deployment plan. Different from the prior art, the present invention starts a new instance and gradually transfers traffic for a smooth transition for an upgradeable container; for a container that cannot be directly upgraded, destroys the old instance, and creates a new instance on an appropriate node to adapt to the updated deployment requirements. Based on the above-mentioned distinguishing technical features, the problems to be solved by the present invention may include: how to improve the stability of the system when the load changes. Specifically, when the container requires higher performance or different resource configuration, the system will start a new container instance. In order to ensure service continuity and reduce the impact on user experience, traffic will gradually migrate from the old container to the new container. This progressive migration strategy helps to smoothly transition to the new resource configuration while avoiding service interruptions caused by sudden switching. For containers that cannot be upgraded in situ to meet new resource requirements, the system will destroy these old containers and then create new container instances on appropriate server nodes according to the updated deployment plan. This process ensures timely updates of resource configurations and optimizes resource allocation to adapt to changing load requirements. That is, by creating new containers and / or destroying old containers, the present invention can ensure that the system remains efficient and stable when handling load changes.

[0025] The present invention provides a serverless function elastic scheduling system based on heterogeneous container combination from a second aspect, the system includes a number of server nodes, and the server nodes include a container resource demand analysis module, a resource monitoring module, a heterogeneous container scheduling module and a resource adjustment output module. The container resource demand analysis module is used to analyze and determine the maximum concurrent requests processed by the container under different resource specifications; the resource monitoring module is used to collect container attribute information of each function; the heterogeneous container scheduling module is used to determine the function deployment plan based on the changes in resource elasticity requirements at different times and different functions, the maximum concurrent requests and container attribute information; the resource adjustment output module is used to configure the container in an in-place upgrade manner based on the function deployment plan, or to configure a non-upgradeable container by creating a new container and / or destroying an old container.

[0026] The system of the present invention improves resource utilization and scaling flexibility. By combining a single function with heterogeneous containers of multiple specifications, the present invention can more effectively utilize fragmented resources on server nodes. This method improves resource utilization of the entire cluster and also enhances scaling flexibility.

[0027] According to a preferred embodiment, the server node also includes a control and feedback module. The control and feedback module is respectively connected to the resource adjustment output module and the heterogeneous container scheduling module, and the resource adjustment output module is connected to the heterogeneous container scheduling module. The control and feedback module is used to receive the scheduling result and update the container deployment result according to the actual deployment effect. The control and feedback module feeds back the container deployment result to the heterogeneous container scheduling module for algorithm optimization. The control and feedback module optimizes resource management and improves the efficiency and effect of resource allocation.

[0028] According to a preferred embodiment, the server node also includes a load balancing module and a function request input module. The load balancing module is communicated with the function request input module and the heterogeneous container scheduling module respectively. The load balancing module analyzes and adjusts the distribution of requests according to the concurrency, processing capacity and current load conditions of each container by the heterogeneous container scheduling module to ensure efficient operation of the system and maximize the use of resources.

[0029] In existing container resource expansion methods, the ability to modify the resource allocation of a container directly without restarting it is called in-place upgrade of container resources. This method is more efficient than creating new container instances. Therefore, while configuring large-scale containers with higher concurrency, rapid resource expansion can be achieved by increasing the resource allocation of existing containers. Doing so can ensure satisfactory request latency performance, thereby improving resource response flexibility.

[0030] The present invention can make full use of the in-situ upgrade of container resources and the function resource combination solution based on heterogeneous containers. When expanding resources, more containers can be created to increase resource allocation, and the resources of existing containers can be increased in-situ, and the concurrency of containers can be improved. In this way, faster and more agile resource expansion can be achieved.

[0031] Finally, it was observed that there is a performance bottleneck when creating containers in parallel on a single server node. This bottleneck causes variations in the speed of container creation on server nodes, depending on the number of containers created. Furthermore, heterogeneous scheduling scenarios on different server nodes exacerbate this variability, resulting in different container creation speeds on each server node. Therefore, it is important to consider the container creation speeds of individual server nodes during container deployment. By considering these speeds, the workload between server nodes can be effectively balanced, achieving more efficient and low-parallel creation of the required containers. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 It is a schematic diagram of the connection relationship of the hardware modules of the server node provided by the present invention;

[0033] Figure 2It is a schematic diagram of the principle of a serverless function elastic scheduling system based on a heterogeneous container combination provided by the present invention;

[0034] Figure 3 It is a logical schematic diagram of a serverless function elastic scheduling method based on heterogeneous container combination provided by the present invention;

[0035] Figure 4 It is a flow chart of a serverless function elastic scheduling method based on heterogeneous container combination provided by the present invention.

[0036] Reference numerals list

[0037] 100: server node; 110: container resource demand analysis module; 120: resource monitoring module; 130: heterogeneous container scheduling module; 140: resource adjustment output module; 150: control and feedback module; 160: load balancing module; 170: function request input module; 200: network communication equipment. DETAILED DESCRIPTION

[0038] The following is a detailed description with reference to the accompanying drawings.

[0039] This invention explains some of the noun terms.

[0040] Container: A virtualization technology that encapsulates the software, code, and dependencies required for an application and all its runtime environments for reliable and consistent deployment in different computing environments. Containers provide a more lightweight, flexible, and portable deployment solution that typically starts faster and takes up fewer resources than traditional virtual machines.

[0041] Container concurrency: refers to the number of requests that the container can process simultaneously. In a serverless computing environment, the concurrency of a container can be determined based on its resource specifications and configured concurrency. For example, in a heterogeneous container environment, a container may be configured with larger CPU and memory resources and set a higher concurrency, so its concurrency may be larger. Another container may be configured with smaller CPU and memory resources and set a lower concurrency, so its concurrency may be smaller.

[0042] Heterogeneous containers: refer to container instances with different resource specifications in a containerized environment. Container instances are usually used to describe a running container in container technology. These containers may differ in hardware configuration, operating environment, performance characteristics, etc. For example, some containers may have larger resource specifications, allocated more memory and CPU resources, and configured with a larger container concurrency, while other containers may have smaller resource specifications, allocated less memory and CPU resources, and configured with a smaller container concurrency. Heterogeneous containers play a key role in containerized environments because they can adapt to different types of workloads and application requirements. By using heterogeneous containers, the system can better utilize the resources in the cluster and respond more flexibly to different load conditions.

[0043] Resource elasticity: refers to the process of dynamically increasing or decreasing the allocated computing resources to meet demand based on changes in system load. In a serverless computing environment, resource elasticity usually includes adjustments in both vertical and horizontal dimensions. Vertical resource elasticity involves increasing or decreasing the resource specifications of a single container, such as adjusting the allocation of CPU and memory. Horizontal resource elasticity involves increasing or decreasing the number of container instances to cope with sudden increases in load.

[0044] Function concurrency: refers to the total concurrent request processing capacity of a serverless function at a specific moment. The concurrency of a function is equal to the sum of the concurrencies of all containers to which the function belongs. For example, a function corresponds to three containers. The CPU of the first container is 1 core, the memory is 2G, and the container concurrency is 1. The CPU of the second container is 2 cores, the memory is 4G, and the concurrency is 2. The CPU of the third container is 4 cores, the memory is 6G, and the concurrency is 3. Therefore, the concurrency of the function is 1+2+3=6.

[0045] Target concurrency of a function: The function concurrency required by a serverless function to meet user performance requirements under a specific sustained request load level. Generally speaking, the higher the function request load level, the higher the target concurrency of the function, and the two are proportional.

[0046] Function deployment plan: Function deployment plan refers to the placement of containers with different resource specifications based on the resource elasticity requirements of serverless functions, according to the target concurrency of the function and the node resources in the cluster. The deployment plan includes the placement locations of all containers and the concurrency configured for each container. In a reasonable deployment plan, it is necessary to consider that the sum of the concurrency of all containers corresponding to the function is equal to a certain specific value. The sum of the CPU and memory of all containers on each server node 100 in the cluster cannot exceed the available resources of the server node 100. Therefore, a deployment plan with a function target concurrency of Q needs to meet the following conditions: (1) The sum of the CPU and memory size of the containers on each server node 100 does not exceed the remaining CPU and memory capacity of the server node 100. (2) The target concurrency of the function is greater than or equal to Q.

[0047] In-place upgrade of container resources: refers to improving the performance or expanding the resources of a container by modifying its resource allocation without restarting it. This method can improve the concurrency performance of a container by increasing its resource allocation, such as CPU and memory, without stopping and restarting the container. In-place upgrade can quickly achieve resource expansion while ensuring satisfactory request latency performance and improving the resource response flexibility of the system.

[0048] The container creation speed of the server node refers to the number of containers created per unit time during the process of deploying containers on a server node 100.

[0049] Function resource combination solution based on heterogeneous containers: A method that uses container instances with different resource specifications to provide the computing resources required by applications. This solution combines the advantages of large containers and small containers, aiming to achieve a balance between resource elasticity and resource utilization efficiency. By combining containers with different resource specifications, this solution can flexibly meet the resource requirements of applications and improve cluster resource utilization.

[0050] The time cost of upgrading containers in place: refers to the time cost required to modify the resource configuration of existing containers when the container deployment plan changes. This includes the time consumption of modifying the CPU and memory allocation of the container and processing the number of concurrent requests and other parameters.

[0051] Example 1

[0052] Large containers and small containers each have unique advantages. Large containers excel in the flexibility of resource allocation. On a single server node 100, the time required to create a large container or a small container is almost the same, which enables large containers to quickly provide resources. Nevertheless, large containers may encounter the problem of resource fragmentation, while small containers have more advantages in scheduling flexibility and can use these fragmented resources more effectively. In addition, small containers enable more server nodes 100 to participate in the scheduling process and increase the speed of resource elasticity by creating containers in parallel. Therefore, designing a function resource combination that can flexibly combine the advantages of large containers and small containers helps to find the best balance between the speed of resource elasticity and resource utilization efficiency.

[0053] The present invention provides a serverless function elastic scheduling method based on heterogeneous container combination, which can also be a function resource combination solution based on heterogeneous containers. The present invention provides the computing resources required by the application by combining containers with heterogeneous resource specifications. Combining the advantages of large and small containers with different resource specifications, a higher cluster resource utilization rate is achieved.

[0054] In view of the shortcomings of the prior art, this embodiment provides a serverless function elastic scheduling method based on heterogeneous container combination. The method is executed by a serverless function elastic scheduling system based on heterogeneous container combination. Figure 2 As shown, the serverless function elastic scheduling system based on heterogeneous container combination of the present invention includes several server nodes 100 and network communication equipment 200.

[0055] The server node 100 is the basic building block of the cluster and is usually composed of a physical server or a virtual machine. Each server node 100 is equipped with hardware resources such as CPU, memory, storage, and network connection components for hosting containers and performing computing tasks. The server node 100 is responsible for running container instances and dynamically expanding or destroying containers according to the deployment plan.

[0056] The network communication device 200 includes routers, switches, etc., which are used to build a communication network within the cluster. These devices are responsible for realizing data transmission and communication between server nodes 100, ensuring interconnection and data exchange between containers. The server node 100 realizes communication connection through the network communication device 200.

[0057] Preferably, the system also includes a storage device. The storage device is used to store the image, data and other related files of the container. These devices can be in the form of local disks, network storage or cloud storage, etc., for providing persistent storage and data sharing services.

[0058] like Figure 1As shown, the server node 100 includes a container resource demand analysis module 110 , a resource monitoring module 120 , a heterogeneous container scheduling module 130 and a resource adjustment output module 140 .

[0059] The container resource demand analysis module 110 and the resource monitoring module 120 are respectively connected to the heterogeneous container scheduling module 130. The input end of the resource adjustment output module 140 is connected to the output end of the heterogeneous container scheduling module 130, and is responsible for generating specific resource adjustment instructions, such as container creation, deletion or in-place upgrade, and sending these instructions to the Kubernetes CRD (Custom Resource Definition) object to achieve in-place vertical elastic scaling of the function.

[0060] The container resource demand analysis module 110 is used to analyze and determine the maximum concurrent requests processed by the container under different resource specifications. The hardware device of the container resource demand analysis module 110 includes a server or a high-performance computer and a memory component having the functions described in the present invention. The memory component is, for example, sufficient RAM to support efficient data processing. The container resource demand analysis module 110 is also satisfied with separately setting a high-speed SSD or HDD for storing analysis data and logs.

[0061] The resource monitoring module 120 is used to collect container attribute information of each function. The hardware equipment of the resource monitoring module 120 includes a server or monitoring device, a network interface card and a sensor. The server or monitoring device is used to monitor resource usage in real time. The network interface card is used to collect resource usage data from different nodes. If it is necessary to monitor the physical hardware status, the sensor may need temperature, voltage and other sensors.

[0062] The heterogeneous container scheduling module 130 is used to determine the function deployment plan based on the changes in resource elasticity requirements at different times and different functions, the maximum request concurrency and container attribute information. The hardware devices of the heterogeneous container scheduling module 130 include high-performance servers, GPUs or TPUs and network switches. High-performance servers are used to run scheduling algorithms and process scheduling tasks. GPUs or TPUs (if the scheduling algorithm requires a lot of calculations) are used to accelerate the calculation process. The network switch is used to efficiently transmit scheduling information between different modules.

[0063] The resource adjustment output module 140 is used to configure the container in an in-place upgrade manner based on the function deployment plan, or to configure a non-upgradeable container by creating a new container and / or destroying an old container. The hardware device of the resource adjustment output module 140 includes a server or a high-performance processor and a large amount of memory (RAM). The server or high-performance processor is used to perform the functions described in the present invention. A large amount of memory (RAM) is used to support the memory requirements of multitasking and container management.

[0064] like Figure 1 As shown, the server node 100 also includes a control and feedback module 150. The control and feedback module 150 is communicatively connected to the resource adjustment output module 140. The resource adjustment output module 140 is communicatively connected to the heterogeneous container scheduling module 130. The control and feedback module 150 is communicatively connected to the heterogeneous container scheduling module 130. The control and feedback module 150 is used to receive the scheduling results and update the container deployment results according to the actual deployment effect. The control and feedback module 150 feeds back the container deployment results to the heterogeneous container scheduling module 130 for algorithm optimization. For example, the container scheduling result corresponding to a certain function is: container 1 is scheduled on server node A, and container 2 is scheduled on server node B. The control and feedback module 150 optimizes resource management and improves the efficiency and effect of resource allocation.

[0065] like Figure 1 As shown, the server node 100 also includes a load balancing module 160 and a function request input module 170. The load balancing module 160 is respectively connected to the function request input module 170 and the heterogeneous container scheduling module 130. The load balancing module 160 analyzes and adjusts the distribution of requests according to the concurrency, processing capacity and current load of each container by the heterogeneous container scheduling module 130.

[0066] like Figure 1 As shown, the function request input module 170 is used to receive the function call request from the API gateway, including the function's running time, bandwidth requirements, concurrency requirements and service chain information. The input end of the heterogeneous container scheduling module 130 is connected to the output end of the load balancing module 160. The input end of the load balancing module 160 is connected to the output end of the function request input module 170, which is responsible for selecting the most suitable container for deployment in the Kubernetes cluster according to the received function request information, and optimizing the location and resource usage of the container according to the preset algorithm.

[0067] The resource monitoring module 120 is designed to monitor the status of containers on the serverless platform, including CPU and memory utilization, concurrency, and server node 100 location, and to count in real time the number of parallel containers created by each server node 100 at every moment.

[0068] like Figure 1 As shown, the load balancing module 160 intelligently analyzes and adjusts the request allocation of each container based on the function deployment plan sent by the heterogeneous container scheduling module 130, including the concurrency, processing capacity, and current load conditions, to ensure efficient operation of the system and maximize resource utilization.

[0069] The container resource demand analysis module 110, the resource monitoring module 120, the heterogeneous container scheduling module 130, the resource adjustment output module 140, the control and feedback module 150, the load balancing module 160 and the function request input module 170 may also be provided with the following hardware as required:

[0070] High-speed network interface: Ensures fast data transfer and communication with containers and other server nodes.

[0071] Storage system: includes solid-state drives (SSDs) and hard disk drives (HDDs). Solid-state drives (SSDs) provide fast read and write speeds and are used to store container images and configuration files. Hard disk drives (HDDs) are used to store large amounts of data and log information.

[0072] Power Supply Unit (PSU): Provides stable power to each module.

[0073] Cooling system: Keeps the hardware running at a suitable temperature to avoid overheating.

[0074] Chassis: Protects the internal hardware and provides structural support.

[0075] Interface cards: such as network interface cards (NICs), which provide network connectivity. They may also include GPUs or other accelerator cards if scheduling and configuration tasks require additional computing power.

[0076] Input / Output Devices: While individual modules may not require direct user interaction, some basic input / output devices may be required for system administration and monitoring.

[0077] Backup power supply (UPS): Provides temporary power when power is interrupted to protect ongoing tasks.

[0078] Monitoring and management systems: Hardware monitoring sensors and management systems to monitor hardware status and performance.

[0079] Security modules: such as firewalls and intrusion detection systems, protect server nodes from unauthorized access.

[0080] like Figure 2As shown, each server node 100 realizes communication connection through the network communication device 200. The function request input module 170 receives an external function call request. The function request input module 170 sends the function call request to the load balancing module 160. The load balancing module 160 forms a forwarding demand according to the function deployment plan and function call request pre-set by the heterogeneous container scheduling module 130. The load balancing module 160 forwards the demand to each heterogeneous container. The container resource demand analysis module 110 sends the resource demand analysis result to the heterogeneous container scheduling module 130. The heterogeneous container scheduling module 130 generates a function deployment plan and sends it to the resource adjustment output module 140 and the load balancing module 160 respectively. The resource adjustment output module 140 sends a control instruction of the scheduling result to the control and feedback module 150. The resource monitoring module 120 feeds back the status to the control and feedback module 150.

[0081] The system of the present invention has the following advantages:

[0082] Improve resource utilization and scaling flexibility: The present invention can more effectively utilize fragmented resources on the server node 100 by combining a single function with heterogeneous containers of various specifications. This method improves resource utilization of the entire cluster and also enhances scaling flexibility.

[0083] Optimize resource management and allocation: The present invention intelligently selects appropriate server nodes 100 to create containers, and integrates the new feature of Kubernetes in-place container vertical scaling. Such a design not only optimizes resource management, but also improves the efficiency and effect of resource allocation.

[0084] Solve performance bottlenecks and resource fragmentation problems: This invention provides an effective solution to the performance bottlenecks and resource fragmentation problems that may be caused by the fine-grained nature of serverless function resources. It reduces the occurrence of performance bottlenecks and the degree of resource fragmentation through reasonable resource combination and layout.

[0085] Algorithm efficiency and practicality: The present invention models the problem of combining and placing heterogeneous containers as an NP-hard problem and designs a heuristic solution based on a greedy algorithm. This algorithm can not only solve the problem in polynomial time, but also has high practicality and implementation efficiency.

[0086] The serverless function elastic scheduling method based on heterogeneous container combination of the present invention mainly includes the following steps: Figure 3 and Figure 4 shown.

[0087] S1: Analyze and determine the maximum number of concurrent requests that can be processed by containers with different resource specifications. Figure 3As shown, the maximum concurrent request quantity is sent to the heterogeneous container scheduling module 130 .

[0088] The container resource demand analysis module 110 will conduct in-depth performance testing and analysis on each function (cloud function deployed by the user) to examine its performance under different container resource specifications (such as CPU and memory size) and different concurrent request numbers.

[0089] For example, for container specifications A and B, you need to evaluate the performance of the function when processing different numbers of concurrent requests under each specification. The following data may be obtained:

[0090] For container size A, the function can handle 10 concurrent requests;

[0091] For container size B, the function is able to handle 15 concurrent requests.

[0092] The following example illustrates the steps of analyzing container resource requirements.

[0093] Suppose there is a cloud computing environment in which multiple different functions are running, and each function needs to run in a container. The goal is to analyze the performance of these functions under different container resource specifications (such as different CPU and memory sizes).

[0094] Select the function and resource specifications to be analyzed: First, select a specific function, such as a function 'Function A' for data processing. Next, determine the resource specifications to be analyzed, such as the CPU resource specifications can be set to 1 core, 2 cores, 4 cores, etc., and the memory specifications can be 1GB, 2GB, 4GB, etc.

[0095] Create multiple test environments: In order to accurately analyze the performance of 'Function A' under different resource specifications, the present invention needs to create multiple container instances of different specifications in the cloud environment. For example, create container instances with 1 core CPU and 1GB memory, 2 core CPU and 2GB memory, and 4 core CPU and 4GB memory for 'Function A'.

[0096] Perform performance testing: Run 'Function A' on each container instance and test its performance at different concurrent request counts. For example, first test 'Function A' on a container with 1 CPU core and 1GB memory with 10, 20, and 30 concurrent requests, and record its performance indicators such as processing speed and response time. Then repeat the same test on containers with 2 and 4 cores.

[0097] Data analysis and recording: Collect and analyze test results to determine the maximum number of concurrent requests that 'Function A' can handle under various resource specifications. For example, you may find that under the conditions of 1 CPU core and 1GB of memory, the performance of 'Function A' drops significantly when processing more than 20 concurrent requests, while under the conditions of 4 CPU cores and 4GB of memory, it can easily handle more than 50 concurrent requests.

[0098] Repeat the above steps for other functions: After completing the analysis of 'Function A', use the same method to analyze other functions to ensure that each function has the best container resource configuration.

[0099] Through this detailed analysis process, we can not only find the most suitable container resource specifications for each function, but also provide strong data support for subsequent resource configuration and optimization, ensuring the efficient operation of the entire cloud computing environment.

[0100] Through this analysis, the maximum number of concurrent requests that a container can handle under various resource specifications can be determined, thereby providing data support for subsequent resource configuration.

[0101] S2: Collect container attribute information of each function.

[0102] The resource monitoring module 120 collects detailed information about the containers of each function, including their resource specifications and specific scheduling locations in the cluster, as well as the number of containers being created.

[0103] Preferably, the resource specification information and / or location information of the container is collected; the running status of the container and / or the available resource status of each server node 100 is monitored. By collecting the container attribute information of each function, detailed data can be provided for resource allocation. Figure 3 As shown, the resource monitoring module 120 sends the collected attribute information to the heterogeneous container scheduling module 130 .

[0104] Specific steps are as follows Figure 4 shown.

[0105] S2l: Detailed resource specification data collection: Collect resource specification information such as CPU and memory of each container and its scheduling position in the cluster. By building a distribution map of containers in the entire cluster, it provides a basis for subsequent resource optimization and scheduling, and provides detailed data for resource allocation.

[0106] For example, existing container management platforms (such as Kubernetes) usually provide a variety of APIs and command line tools that can be used to query detailed information about containers, including resource specifications such as CPU and memory. By calling these APIs or using related command line tools, you can easily obtain container resource specification data.

[0107] S22: Container deployment location tracking: Record the specific location of each container in the cluster, including the physical nodes or virtual nodes where they are located. The physical nodes or virtual nodes are shown in Table 1.

[0108] Table 1: Exemplary data of physical nodes or virtual nodes

[0109] Container name node CPU Memory Pod A Node 1 1 core 2GB Pod B Node 2 3 cores 6GB

[0110] The present invention tracks the container deployment position and can achieve multiple functions.

[0111] Resource utilization optimization: By recording the specific location of each container in the cluster, the system can better understand the resource utilization of each server node 100 in the cluster. This helps the system select server nodes 100 with lower resource utilization when deploying containers, thereby achieving optimal resource utilization.

[0112] Troubleshooting and debugging: When a system fails or has performance issues, the deployment location of the container can be accurately tracked and can help system administrators locate the root cause of the problem more quickly. By knowing the server node 100 where the container is located, possible hardware failures or network problems can be quickly located.

[0113] Load balancing: By understanding where containers are deployed in the cluster, the system can better balance the load.

[0114] S23: Real-time monitoring of operating status: Continuously monitor the operating status of each container, including performance indicators and health status, as shown in Table 2.

[0115] Table 2: Example data of the running status of the container

[0116]

[0117] S24: Resource usage monitoring: continuously monitoring the available resource status of each server node 100, including the allocated CPU utilization and memory utilization.

[0118] Existing container management platforms (such as Kubernetes, Docker Swarm, etc.) generally provide a monitoring function for node resource utilization. By querying the API of the management platform or using the graphical interface of the management platform, information such as the CPU utilization and memory utilization of each server node 100 can be obtained.

[0119] Monitoring resource utilization can help resource elasticity better understand the resource utilization of each server node 100 in the cluster and promptly discover insufficient or overloaded server nodes 100. By analyzing resource utilization data, reasonable resource adjustments and optimizations can be made to improve system performance and stability.

[0120] S25: The resource monitoring module 120 counts the number of containers being created in parallel on each server node 100, which will affect the speed of creating new containers. The status of all containers can be accessed through the Kubernetes API, so as to count the number of containers created in parallel on different server nodes 100.

[0121] The purpose of doing this is to estimate the container creation speed of different server nodes 100 in real time, so as to more accurately calculate the function expansion cost and obtain a more optimized function deployment plan.

[0122] S3: Determine a function deployment plan based on the changes in resource elasticity requirements at different times and for different functions, the maximum concurrent requests, and container attribute information. The function deployment plan is sent to the resource adjustment output module 140 by the heterogeneous container scheduling module 130 .

[0123] This decision-making process considers various possible resource combinations of containers with different resource specifications to achieve the best resource elasticity performance and cluster resource utilization.

[0124] S31: Calculate the deployment cost and concurrency of each container specification on different server nodes 100 and under different container concurrency amounts. The deployment cost is equal to the sum of the expansion cost and the resource cost.

[0125] S32: Select a container specification and server node combination with the minimum deployment overhead per unit concurrency according to the deployment cost and concurrency of the container specification.

[0126] Through these two steps, the present invention can formulate a final optimized container deployment plan to minimize costs. In the selection process, ensure that the resource requirements of each container do not exceed the remaining resources of the server node 100. The most cost-effective container and node combination is selected one by one through a greedy algorithm until the target concurrency is reached.

[0127] S33: Final deployment plan formulation: Based on the above selection process, formulate the final optimized container deployment plan to minimize costs.

[0128] S4: Configure containers in an in-place upgrade manner based on the function deployment plan, or configure non-upgradeable containers by creating new containers and / or destroying old containers.

[0129] S41: The method for configuring a container in an in-place upgrade manner based on a function deployment plan includes: directly and dynamically changing the resource configuration and the concurrent number of requests processed of the container without recreating the container to achieve rapid resource elastic response.

[0130] In-place upgrading of container resources is more efficient than creating new containers. The present invention can modify the resource allocation of a container without restarting the container. Therefore, it is possible to increase the resource allocation of existing containers while configuring a larger container with higher concurrency, achieve rapid resource expansion, and ensure satisfactory request latency performance, thereby improving resource response flexibility.

[0131] S42: The method for configuring a non-upgradeable container by creating a new container and / or destroying an old container includes: for a container that needs to upgrade resource configuration, smoothly switching to a new container configuration by starting a new container instance and gradually migrating traffic. For containers that cannot directly upgrade resource configuration, destroy the old container and create a new container instance on the appropriate server node 100 to meet the updated deployment plan. Creating new containers and / or destroying old containers can ensure that the system remains efficient and stable when handling load changes.

[0132] The present invention innovatively considers the key indicator of server node container creation speed into the container placement decision, designs a deployment cost evaluation algorithm, and formulates the best container specification selection and combined deployment plan through a heuristic algorithm. By continuously updating the function deployment plan, optimizing container deployment, determining whether a new container needs to be created, determining containers suitable for in-situ resource upgrade and expansion, and managing container destruction. Throughout the process, we focus on improving the expansion speed of function resources and are committed to balancing the utilization of fragmented resources within the cluster, thereby reducing the cost of the cloud platform.

[0133] The present invention describes step S31 in detail.

[0134] S311: The method for calculating the deployment cost includes: evaluating the time consumption data generated by the container change in the container deployment plan to determine the expansion cost; and evaluating the resource cost of all containers in the container deployment plan.

[0135] Specifically, the time consumption of changing from one container deployment plan to another is inversely proportional to the agility of resource expansion. Specifically, the expansion cost includes the time overhead of upgrading the container in place and the time overhead required to create a new container. The process of creating a new container includes the overhead of pulling the container image and the time overhead of cold starting the container.

[0136] The prior art usually achieves resource expansion by recreating or adding new container instances. This method may result in a longer startup time because operations such as pulling images and initializing container environments are required, thereby increasing system response delays. At the same time, the prior art does not take into account the expansion cost in the process of deciding the placement of containers. Therefore, the container deployment plan of the prior art often results in an imbalance in the creation of containers on different server nodes 100, resulting in performance bottlenecks. In contrast, the present invention takes into account the calculation of expansion costs, making the container deployment plan more intelligent and efficient. The present invention also dynamically adjusts the container resource cost to keep it consistent with the node resource utilization.

[0137] The higher the expansion cost, the more time it takes to switch from the current deployment state to the target deployment state. This comprehensive cost assessment of different expansion methods helps the system make more informed decisions when expanding resources and achieve faster function resource elasticity. By accurately evaluating the expansion cost, the system can better plan and optimize the allocation of resources, thereby improving the elasticity and efficiency of the system.

[0138] In the present invention, the pulling overhead of the container image refers to the time cost required to obtain the required container image from the image repository when performing an in-place upgrade of the container or creating a new container. This includes the network transmission time for downloading the image file from the remote repository and the time required to decompress the image file. For example, if the system needs to pull a container image containing an application and its dependencies from a remote image repository to the local computing server node 100, this process may be affected by factors such as network bandwidth and image file size, thereby affecting the time overhead for pulling the image.

[0139] Expansion cost S f It is the average time required for a serverless function f to update its target concurrency. Calculate the scaling cost S for a single container np If container p is upgraded in-place on server node n, its expansion cost is represents the expansion cost of performing an in-place upgrade on server node n. If a new container p is created on server node n, its expansion cost is where k n Indicates the number of resource competitions when creating containers between server nodes n, I p The time overhead of pulling the container image.

[0140] The formula is:

[0141]

[0142] Calculate the total expansion cost S of the function f The total expansion cost is the weighted average of all container expansion costs, with the weight being the number of concurrent users Qp , the formula is:

[0143]

[0144] X np Indicates whether container p is scheduled on node n. p is scheduled on node n, X np =1 means container p is scheduled on node n. np =0 means that container p is not scheduled on node n.

[0145] S312: Initialize the function deployment plan and the current total concurrency, and select the most cost-effective container specification and server node 100 based on the target concurrency and the calculation result of the deployment cost per unit concurrency of each server node 100. Update the container deployment plan and node resources according to the selection result. When the current total concurrency reaches or exceeds the target concurrency, return the final container deployment plan.

[0146] Specifically, the resource cost of all containers in a container deployment scheme is evaluated. By associating the node resource price with the resource utilization of the server node 100. When the resource utilization of the server node 100 is high, the resource price of the container is reduced, and at a low utilization of the server node 100, the price of the container resource will rise. The calculation of the resource cost takes into account the CPU and memory resource prices of each server node 100, as well as the resource usage of the container on the server node 100. The prior art usually adopts a fixed resource cost. The prior art usually adopts a fixed resource cost to evaluate the container deployment scheme, which means that regardless of the resource utilization of the server node 100, the resource price of the container remains unchanged. The main defect of this method is that it does not take into account the impact of changes in node resource utilization on the container resource cost. Therefore, when the node resource utilization is high, there may be a problem of resource waste, and when the node resource utilization is low, insufficient resources may occur.

[0147] Resource cost B f It refers to the total resource cost of all containers of the deployed function f. Calculate the resource price of a single server node 100 and The c in it stands for CPU. Indicates the cost of the CPU. The m in stands for mem. Represents the cost of memory. The price of CPU and memory is related to their utilization, where x is the price fluctuation ratio.

[0148]

[0149] Indicates the total amount of remaining CPU resources on server node n. Indicates the total amount of memory resources remaining on server node n. n Indicates the total amount of CPU resources of server node n. n Indicates the total amount of memory resources of server node n. Calculate the resource cost of the container B np ,The resource cost of a container is the sum of its CPU and memory resource prices.

[0150]

[0151] C p Indicates the CPU requirement of container p. p Indicates the memory requirement of container p. Calculate the total resource cost of the function B f The total resource cost is the weighted average of all container resource costs, with the weight being the concurrent Q p .

[0152]

[0153] In the steps of the present invention, selecting the minimum container specification and server node combination means selecting the container specification and server node combination with the lowest deployment cost to ensure the maximization of resource utilization efficiency and cost-effectiveness.

[0154] The present invention improves the deficiencies of the prior art by introducing a dynamic resource cost calculation method. In the present invention, the calculation of resource cost not only takes into account the CPU and memory resource prices of each server node 100, but also associates the resource utilization of the server node 100 with the resource price of the container. Specifically, when the resource utilization of the server node 100 is high, the resource price of the container will be reduced to reflect the full utilization of the node resources; when the node resource utilization is low, the price of the container resources will increase to encourage more efficient utilization of the node resources. The core of the improvement of the present invention is to dynamically adjust the container resource price to keep it consistent with the node resource utilization. This improvement brings the following advantages:

[0155] Resource utilization optimization: By dynamically adjusting the container resource price, node resources can be better utilized, resource waste and shortage problems can be avoided, and the resource utilization and efficiency of the entire system can be improved.

[0156] Cost savings: When node resource utilization is high, lowering container resource prices can reduce deployment costs, while when node resource utilization is low, raising container resource prices can encourage more economical use of resources, thereby reducing costs.

[0157] Performance improvement: Dynamically adjusting container resource prices can better balance the system load and avoid resource bottlenecks, thereby improving system performance and stability.

[0158] The present invention provides necessary information for optimizing container deployment solutions through dynamic calculation of resource costs, thus laying the foundation for the system to achieve intelligent and efficient resource management. Among them, the resource cost calculation results are used when making container placement decisions, and the system can select the optimal node to deploy the container to maximize resource utilization. At the same time, with the help of resource cost calculation results, dynamic resource adjustment enables the system to flexibly adjust container resource allocation, respond to resource bottlenecks and imbalances, and meet system performance and cost requirements. Most importantly, through the dynamic calculation of resource costs, the system can achieve cost-effectiveness optimization and adjust the container resource price according to the node resource utilization to achieve a balance between cost and performance, thereby improving resource utilization efficiency and reducing deployment costs.

[0159] The present invention provides a detailed description of the cost optimization heuristic algorithm in step S32.

[0160] Cost optimization heuristic algorithm: According to the deployment cost and concurrency of the container specifications, select the container specification and server node combination with the lowest deployment overhead per unit concurrency. During the selection process, ensure that the resource requirements of each container do not exceed the remaining resources of the server node 100. The most cost-effective container and server node combination is selected one by one through the heuristic algorithm until the target concurrency is reached.

[0161] S321: Initialize function deployment plan: Initialize function deployment plan R f (Q'), where the number of all containers on all server nodes 100 is X np are all set to 0. This means that initially no containers are deployed.

[0162] S322: Initialize the current total concurrent volume: Initialize the current total concurrent volume Q curr Initialized to 0, indicating that no container is selected at the beginning.

[0163] S323: Select the most cost-effective container specification and server node 100.

[0164] Loop selection until the current total concurrent volume Q curr Achieve or exceed the target concurrency Q'.

[0165] At each step, calculate the deployment cost D per unit concurrency of each container specification on each server node 100 np / Q p , and selects the combination of container specifications and server nodes with the minimum deployment cost. np Q represents the deployment cost of container specification p on server node n. p Indicates the number of concurrent connections.

[0166] If the CPU requirement of the container is C p or memory requirement M p Exceed the remaining resources of server node n or Then skip this combination.

[0167] Selecting the minimum container specification and server node combination in step S323 means selecting the container specification and server node combination with the lowest deployment cost to ensure maximum resource utilization efficiency and cost-effectiveness.

[0168] For example, suppose that in a certain step, there are two container specifications (A and B) and three server nodes (Node1, Node2, and Node3), and their deployment costs are as follows:

[0169] The deployment cost of container specification A on Node1 is 10, the deployment cost on Node2 is 15, and the deployment cost on Node3 is 12.

[0170] The deployment cost of container specification B on Node1 is 12, the deployment cost on Node2 is 14, and the deployment cost on Node3 is 11.

[0171] In this case, choosing the smallest combination of container specifications and server nodes means choosing the combination with the lowest deployment cost. Assuming that the current total concurrency has not yet reached the target concurrency, and a server node 100 needs to be selected to deploy the container, then choosing container specification A on Node1 has the lowest deployment cost, which is 10, because it is the smallest value. The reason for this choice is that it can meet current needs at the lowest cost and will not cause waste of resources.

[0172] If in another case, the deployment cost of container specification A on Node2 is also the lowest, but the remaining resources on Node2 are not enough to meet the container requirements (insufficient CPU or memory), then this combination will be skipped. The reason for skipping is that although the deployment cost is the lowest, the resources of server node 100 are insufficient to create a container. Therefore, when selecting the minimum container specification and server node combination, not only the cost should be considered, but also whether the node resources meet the container requirements to ensure the feasibility and effectiveness of the deployment plan.

[0173] S324: Update deployment plan and node resources:

[0174] After selecting the optimal combination, update the deployment plan R f (Q').

[0175] The CPU and memory resources of the corresponding server node 100 are subtracted.

[0176] Increase the current total concurrent volume Qcurr .

[0177] S325: Return the final deployment plan: curr When the target concurrency Q' is reached or exceeded, the final container deployment plan R is returned. f (Q').

[0178] S33: Final deployment plan formulation: Based on the above selection process, formulate the final optimized container deployment plan to minimize costs.

[0179] Optionally, define the deployment plan of function f as R f ={(n,p,X np )|n∈N,p∈P f}. This plan records the deployment of containers of different specifications of function f in the cluster. Where N represents the set of server nodes in the cluster, P f represents the set of container specifications available to function f, X np It indicates the number of containers of specification p deployed on server node n.

[0180] The present invention further describes step S4.

[0181] S4: In-place configuration upgrade of containers: When implementing the updated deployment plan, the system will perform operations on the containers that can be configured and upgraded on the current server node 100. This in-place upgrade method allows the system to dynamically change the resource configuration of the container and the number of concurrent requests processed without recreating the container, achieving rapid resource elasticity response. Resource elasticity refers to elastic expansion. Rapid resource elasticity refers to the rapid increase of container resources. Figure 3 As shown, the resource adjustment output module 140 sends the formed scheduling result to the control and feedback module 150. The control and feedback module 150 feeds back the updated container deployment result to the heterogeneous container scheduling module 130.

[0182] In the framework of the present invention, in order to more intuitively describe the technical solution of the present invention, it is named "COMBOFUNC". In this process, two core components are mainly involved: 'CF' and 'InPlaceDeployment' controller, both of which are implemented and applied in the Kubernetes environment, among which InPlaceDeployment is just a naming method.

[0183] 'COMBOFUNC', as a key component of the present invention, refers to a structure based on Kubernetes Custom Resource Definition (CRD), which represents a set of multi-specification containers associated with a specific function. In this way, the present invention can effectively manage multiple container instances belonging to the same function, each of which may have different CPU, memory, and concurrency performance configurations. In fact, 'COMBOFUNC' can be regarded as a collection of multiple 'Deployment' of different specifications. Such a design makes resource scheduling and management more flexible and efficient.

[0184] On the other hand, the 'InPlaceDeployment' controller is designed to solve the problem that the InPlace Pod Vertical Scaling mechanism in Kubernetes does not support the 'Deployment' resource object. The present invention defines 'InPlaceDeployment' through CRD and implements a CRD controller to allow the Pod in the 'Deployment' to support the feature of in-place vertical scaling. This means that when the resource configuration of the container needs to be adjusted (for example, to increase CPU or memory resources), it can be done directly on the existing Pod without the need to delete and rebuild it.

[0185] In the practice of the present invention, the 'COMBOFUNC' Kubernetes controller uses the Kubernetes list-watch mechanism to monitor the update of the 'COMBOFUNC' resource in real time, and then creates, deletes or modifies the 'InPlaceDeployment' resource object in real time. Such a mechanism ensures that the system can respond quickly and effectively when resource configuration needs to be adjusted, ensuring the efficient operation of the system and the optimal use of resources. At the same time, through this design, the present invention also improves the system's adaptability to dynamic load changes, thereby enhancing the stability and reliability of the overall system.

[0186] like Figure 3 As shown, the function request input module 170 receives and analyzes the function call request received from the API gateway, including the function's running time, bandwidth requirements, concurrency requirements, and service chain information.

[0187] The load balancing module 160 analyzes and adjusts the distribution of requests based on the concurrency, processing capacity and current load of each container by the heterogeneous container scheduling module 130 .

[0188] Example 2

[0189] This embodiment is a further explanation of Embodiment 1, and repeated contents will not be repeated here.

[0190] This embodiment provides an application case of a serverless function elastic scheduling method and system based on a combination of heterogeneous containers.

[0191] On a large online retail platform, millions of users visit the website to shop every day. The business logic of shopping is deployed in the cloud in the form of serverless functions. During certain promotional events, the website traffic may suddenly surge, causing a sharp increase in load. Traditional serverless architectures are unable to cope with this sudden increase in traffic, which may cause the website to crash or severely reduce the response speed, affecting user experience and sales.

[0192] Traditional automatic expansion mechanisms cannot respond to burst traffic in a timely manner because container creation takes a long time and cold start time increases latency. Traditional resource management strategies, which allow a function to correspond to homogeneous container resource specifications, may lead to cluster resource fragmentation, inability to fully utilize cluster resources, and reduced resource utilization efficiency.

[0193] In the scenario of large-scale online retail platforms, the various modules of the COMBOFUNC system will play a key role in addressing the challenges of sudden traffic growth.

[0194] Function request input module 170 is responsible for receiving function call requests from the API gateway. During the promotion period, sudden shopping requests will be passed into the system through this module.

[0195] The heterogeneous container scheduling module 130 obtains the best container deployment plan based on the heuristic algorithm.

[0196] The resource adjustment output module 140 generates specific resource adjustment instructions, such as container creation, deletion, or in-place upgrade, based on the output of the heterogeneous container scheduling module 130, and sends these instructions to the Kubernetes CRD object to achieve in-place vertical elastic scaling of the function. During burst traffic, it will quickly adjust the resource allocation of existing containers to respond to user shopping requests.

[0197] The control and feedback module 150 is used to receive the scheduling results of the resource adjustment output module 140 and implement the function deployment plan according to the actual deployment effect. Through continuous feedback and adjustment, the system can ensure that the function deployment plan can be implemented.

[0198] The resource monitoring module 120 monitors the status of containers on the serverless platform in real time, including CPU and memory utilization, concurrency, and the location of the server node 100. During burst traffic, it will help the system to promptly discover resource bottlenecks and performance issues, and provide data support to other modules for intelligent scheduling and optimization.

[0199] In this scenario, the load balancing module 160 of the COMBOFUNC system will also play an important role, intelligently analyzing and adjusting the request allocation of each container based on the concurrency, processing capacity and current load of the resource monitoring module 120 to ensure efficient operation of the system and maximize resource utilization. In this way, the COMBOFUNC system will be able to effectively cope with the challenges of sudden traffic growth of large online retail platforms and ensure system stability and user experience. Through COMBOFUNC, the online retail platform can achieve the following advantages:

[0200] Real-time response: COMBOFUNC's rapid resource expansion and flexible deployment strategy enable the platform to respond to sudden traffic in real time, ensuring stable website operation and user experience.

[0201] Improved resource utilization: COMBOFUNC's intelligent resource management and deployment strategy effectively avoids resource fragmentation, fully utilizes cluster resources, and reduces costs.

[0202] Automated operation and maintenance: COMBOFUNC provides automated container deployment and management functions, reducing manual intervention and improving operation and maintenance efficiency.

[0203] It should be noted that the above-mentioned specific embodiments are exemplary, and those skilled in the art can come up with various solutions inspired by the disclosure of the present invention, and these solutions also belong to the disclosure scope of the present invention and fall within the protection scope of the present invention. Those skilled in the art should understand that the present invention specification and its drawings are illustrative and do not constitute a limitation on the claims. The scope of protection of the present invention is defined by the claims and their equivalents. The present invention specification contains multiple inventive concepts, such as "preferably" and "according to a preferred embodiment", which means that the corresponding paragraph discloses an independent concept, and the applicant reserves the right to file a divisional application based on each inventive concept.

Claims

1. A serverless function elastic scheduling method based on heterogeneous container combination, It is characterized in that The method comprises: Analyze and determine the maximum number of concurrent requests that can be processed by containers with different resource specifications; Collect container attribute information of each function; Determine a function deployment plan based on changes in resource elasticity requirements at different times and for different functions, the maximum concurrent request volume, and the container attribute information; The container is configured in an in-place upgrade manner based on the function deployment plan, or a non-upgradeable container is configured in a manner of creating a new container and / or destroying an old container.

2. According to claim 1, the serverless function elastic scheduling method based on heterogeneous container combination, It is characterized in that Methods for collecting container attribute information for each function include: Collect resource specification information and / or location information of the container; The operating status of the container and / or the available resource status of each server node (100) is monitored.

3. According to the serverless function elastic scheduling method based on heterogeneous container combination according to claim 1 or 2, It is characterized in that The method for determining a function deployment plan includes: Calculate the deployment cost and concurrency of each container specification on different server nodes (100) and with different container concurrency; A combination of container specifications and server nodes with the lowest deployment overhead per unit concurrency is selected according to the deployment cost of the container specifications and the concurrency.

4. The serverless function elastic scheduling method based on heterogeneous container combination according to any one of claims 1 to 3, It is characterized in that The deployment cost includes expansion cost and resource cost; The method for calculating the deployment cost includes: Evaluating the time consumption data generated by container changes in the container deployment plan to determine the expansion cost; The resource costs of all containers in the container deployment solution are evaluated.

5. According to claim 3, the serverless function elastic scheduling method based on heterogeneous container combination, It is characterized in that The method for determining a function deployment plan further includes: Initialize the function deployment plan and the current total concurrency. Selecting the most cost-effective container specification and server node (100) based on the target concurrency and the calculation result of the deployment cost per unit concurrency of each server node (100); Update the container deployment plan and node resources based on the selection results; When the current total concurrency reaches or exceeds the target concurrency, the final container deployment plan is returned.

6. The serverless function elastic scheduling method based on heterogeneous container combination according to any one of claims 1 to 5, It is characterized in that The method for configuring the container in an in-place upgrade manner based on the function deployment plan includes: Without recreating the container, the resource configuration of the container and the concurrent number of requests processed are directly and dynamically changed to achieve rapid resource elastic response.

7. The serverless function elastic scheduling method based on heterogeneous container combination according to any one of claims 1 to 6, It is characterized in that The method for configuring a non-upgradeable container in a manner of creating a new container and / or destroying an old container comprises: For containers that require resource configuration upgrades, smoothly switch to the new container configuration by starting new container instances and gradually migrating traffic. For containers whose resource configuration cannot be directly upgraded, the old container is destroyed and a new container instance is created on an appropriate server node (100) to meet the updated deployment plan.

8. A serverless function elastic scheduling system based on heterogeneous container combination, It is characterized in that The system comprises a plurality of server nodes (100), wherein the server nodes (100) comprise: Container resource demand analysis module (110): analyzes and determines the maximum concurrent requests processed by containers under different resource specifications; Resource monitoring module (120): collects container attribute information of each function; A heterogeneous container scheduling module (130): determining a function deployment plan based on changes in resource elasticity requirements at different times and for different functions, the maximum concurrent request volume, and the container attribute information; Resource adjustment output module (140): configures the container in an in-place upgrade manner based on the function deployment plan, or configures a non-upgradeable container in a manner of creating a new container and / or destroying an old container.

9. According to claim 8, the serverless function elastic scheduling system based on heterogeneous container combination, It is characterized in that The server node (100) further comprises a control and feedback module (150), The control and feedback module (150) is respectively connected in communication with the resource adjustment output module (140) and the heterogeneous container scheduling module (130), and the resource adjustment output module (140) is connected in communication with the heterogeneous container scheduling module (130). The control and feedback module (150) is used to receive the scheduling result, and update the container deployment result according to the actual deployment effect, and feed back the container deployment result to the heterogeneous container scheduling module (130) for algorithm optimization.

10. The serverless function elastic scheduling system based on heterogeneous container combination according to claim 8 or 9, It is characterized in that The server node (100) further comprises a load balancing module (160) and a function request input module (170). The load balancing module (160) is respectively connected to the function request input module (170) and the heterogeneous container scheduling module (130). The load balancing module (160) analyzes the concurrency, processing capacity and current load conditions of each container according to the heterogeneous container scheduling module (130) and adjusts the distribution of requests.

Images