Container resource management method and device, electronic equipment and medium

Abstract

The invention provides a container resource management method and device, electronic equipment and a medium, and relates to the technical field of cloud computing. The method comprises the following steps: scanning stock resources of each node device of a service node, and constructing a resource topology model; on the basis of the resource topology model, according to the access performance parameters among the resources in the service node, determining a cost factor of the Pod for performing cross-domain access on the resources on the service node; the optimal resource combination of the Pod in the resource topology model is determined by minimizing a target function according to the Qos type of resource allocation of the Pod on the service node, and the target function is obtained based on cost factor construction. Through the technical scheme provided by the invention, the problems of high access cost, limited performance and low refinement degree of resource allocation when Pod uses hardware resources of a service node in related technologies are solved, resource optimization allocation is performed according to different service types of Pod, the access cost of Pod node-level resource allocation is reduced, and the resource allocation efficiency is improved. And the access performance and the refinement degree are improved.

Description

Technical Field

[0001] The present disclosure relates to the technical field of cloud computing, and in particular to a container resource management method, device, electronic device and medium. Background Art

[0002] For server hardware, the central processing unit (CPU), memory controller, input / output (I / O) devices and other peripherals are interconnected to form a rather complex network. After the above hardware resource combination is assigned to a Pod instance, the performance of the task load running on the Pod will vary greatly due to the different data transmission lines and transmission efficiency between resources and the different degree of coordination between resources. In the related technology, the hardware architecture on the server node is relatively fixed, Kubernetes has insufficient node-level resource management functions, the hardware resources on the node are usually oversimplified, and Kubernetes has limited support for node non-uniform memory access (NUMA) configuration. Directly transplanting the NUMA node core binding strategy to the container scenario has the problems of high access cost and limited performance of hardware resources, as well as low degree of refinement of resource allocation. Summary of the invention

[0003] The present disclosure provides a container resource management method, device, electronic device, chip and medium to solve the problems of insufficient refinement of resource allocation, high access cost and low performance of hardware resources, and low refinement of resource allocation in related technologies. By performing refined resource allocation on Pods, the access cost of node-level resource allocation is reduced, and the access performance and refinement of resource allocation are improved.

[0004] A first aspect of the present disclosure provides a container resource management method, the method comprising: scanning the stock resources of each node device of the service node, building a resource topology model, the stock resources comprising at least one of a CPU, a memory, a GPU, and an I / O device;

[0005] Based on the resource topology model and the access performance parameters between resources in the service node, the cost factor of the Pod's cross-domain access to each resource on the service node is determined;

[0006] According to the QoS type of resource allocation of the Pod on the service node, the optimal resource combination of the Pod in the resource topology model is determined by minimizing the objective function, where the objective function is constructed based on the cost factor.

[0007] In one embodiment of the present disclosure, based on the resource topology model and according to the access performance parameters between the resources in the service node, the cost factor of the cross-domain access of the Pod to the resources on the service node is determined, including:

[0008] Match the available resources in the resource topology model according to the upper limit of the target resources to be occupied by the Pod;

[0009] If the available resources are less than the upper limit, the performance parameters for cross-domain access between resources are calculated from the lower resources to the upper resources according to the hierarchical relationship of the resource topology model;

[0010] Based on upper-layer resources, lower-layer resources, and performance parameters, calculate the cost factor of cross-domain access of Pods on service nodes.

[0011] In one embodiment of the present disclosure, according to the hierarchical relationship of the resource topology model, the performance parameters of cross-domain access between resources are calculated step by step from the lower layer resources to the upper layer resources, including:

[0012] Obtaining a first cross-domain access indicator between basic hardware units in the lower-layer resources, wherein the basic hardware unit includes any one of a CPU core Core, a dynamic random access memory DRAM, and a GPU stream processing unit, and the first cross-domain access indicator includes at least the number of accesses, the network bandwidth, and the access delay;

[0013] According to the number of lower-layer resources under the upper-layer resource and the first cross-domain access index, a second cross-domain access index between the upper-layer resources is counted;

[0014] If the available resource matched by the target resource is a lower-layer resource, the first cross-domain access indicator is used as a performance parameter;

[0015] If the available resource matched by the target resource is an upper-layer resource, the second cross-domain access indicator is used as a performance parameter.

[0016] In one embodiment of the present disclosure, based on upper-layer resources, lower-layer resources and performance parameters, the cost factor of cross-domain access of Pod on the service node is counted, including:

[0017] Determine a first cost factor for cross-domain access between lower-layer resources based on the performance parameter;

[0018] Determining a second cost factor of the upper-layer resource according to the lower-layer resource and the first cost factor, wherein the lower-level node of the upper-layer resource in the resource topology model includes the lower-layer resource;

[0019] The cost factor is determined according to the first cost factor and the number of upper-layer resources, the second cost factor and the number of lower-layer resources.

[0020] In one embodiment of the present disclosure, according to the QoS type of resource allocation of the Pod on the service node, the optimal resource combination of the Pod in the resource topology model is determined by minimizing the objective function, including:

[0021] Determine a first objective function as an objective function according to a cost factor, an idleness of available resources, a Shannon entropy of a resource allocation ratio of each layer in a resource topology model, and a control factor;

[0022] Based on the preset constraints and QoS type, the first objective function is minimized to determine the first optimal solution of the optimal resource combination;

[0023] If the number of the first optimal solution is equal to 1, resources are allocated to the Pod based on the first optimal solution and the QoS type;

[0024] If the number of the first optimal solutions is greater than or equal to 2, the preset objective function group is traversed according to the priority order, and each objective function in the preset objective function group is minimized to solve the second optimal solution until the number of the second optimal solutions converges to one. Then, based on the second optimal solution, resources are allocated to the Pod according to the Qos type, where the priority order is that the cross-domain access priority of the lower-level resources is higher than the cross-domain access priority of the upper-level resources.

[0025] In one embodiment of the present disclosure, based on preset constraints and QoS types, minimizing a first objective function and determining a first optimal solution for an optimal resource combination includes:

[0026] If the QoS type is resource-sensitive, the control factor is set to a positive value, and the first objective function is minimized to obtain the first optimal solution;

[0027] If the QoS type is resource sharing or resource overselling, the control factor is set to a negative value, and the first objective function is minimized to obtain the first optimal solution.

[0028] In one embodiment of the present disclosure, based on the first optimal solution, resources are allocated to the Pod according to the QoS type, including:

[0029] If the QoS type is resource-sensitive, the first priority is used to exclusively occupy the target resource for the Pod according to the first optimal solution;

[0030] If the QoS type is resource sharing, a portion of the target resources is allocated to the Pod with the second priority according to the first optimal solution;

[0031] If the QoS type is resource oversale, the target resources are recovered for the Pod with the third priority according to the first optimal solution, wherein the priorities of the first priority, the second priority and the third priority decrease in sequence.

[0032] In one embodiment of the present disclosure, according to the priority order, the preset objective function group is traversed, and each objective function in the preset objective function group is minimized to solve the second optimal solution, until the number of second optimal solutions converges to one, then based on the second optimal solution, resources are allocated to the Pod according to the Qos type, including:

[0033] Determine the first ratio based on the Pod's applied resources and available resources;

[0034] Determine the second ratio based on the applied similar resources and available similar resources of the Pod;

[0035] Based on the first ratio and the second ratio, determining a second objective function, the second objective function belonging to a preset objective function group;

[0036] According to the QoS type, adjust the weight parameters of the first ratio and the second ratio to minimize the second objective function. If the number of optimal solutions obtained is one, use the optimal solution as the second optimal solution, and allocate resources to the Pod based on the second optimal solution.

[0037] If the number of optimal solutions obtained is greater than or equal to two, the number of cross-domain accesses of lower-level resources or upper-level resources is determined based on the order from child nodes to root nodes in the resource topology model, and the resources of the node with the smallest number of cross-domain accesses are allocated to the Pod.

[0038] In one embodiment of the present disclosure, according to the first optimal solution, the Pod is exclusively occupied with the target resource with the first priority, including:

[0039] Obtain the maximum amount of target resources and the basic specification resources of target resources;

[0040] Determine the first quantity of the basic specification resources that the Pod exclusively occupies the target resources according to the maximum quota resources and the basic specification resources;

[0041] The first quantity is rounded up to obtain the target quantity, and the target quantity of basic specification resources is used as the target resources exclusively occupied by the Pod.

[0042] In one embodiment of the present disclosure, the method further includes:

[0043] Get the target resource access cost value of the target resource model;

[0044] Monitor the actual resource access cost value of resource allocation of all existing Pods on the service node;

[0045] Based on the actual resource access cost value and the target resource access cost value, the additional access cost between each Pod is traversed on the service node through a greedy algorithm;

[0046] The number of target Pods in the statistical service node that satisfy an additional access cost greater than or equal to a preset threshold is the second number;

[0047] If the second number exceeds the preset ratio, based on the resource topology model and according to the access performance parameters between the resources in the target Pod, determine the cost factor for the target Pod to perform cross-domain access to each resource on the service node;

[0048] According to the QoS type of resource allocation of the target Pod on the service node, the optimal resource combination of the target Pod in the resource topology model is determined by minimizing the objective function, where the objective function is constructed based on the cost factor.

[0049] A second aspect of the present disclosure provides a container resource management device, the device comprising:

[0050] A topology model building module is used to scan the stock resources of each node device of the service node and build a resource topology model. The stock resources include at least one of CPU, memory, GPU, and I / O device.

[0051] The access cost determination module is used to determine the cost factor of the cross-domain access of the Pod to each resource on the service node based on the resource topology model and the access performance parameters between the resources in the service node;

[0052] The resource allocation module is used to determine the optimal resource combination of the Pod in the resource topology model by minimizing the objective function according to the QoS type of resource allocation of the Pod on the service node, where the objective function is constructed based on the cost factor.

[0053] The third aspect embodiment of the present disclosure proposes an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute any one of the methods in the first aspect embodiment of the present disclosure.

[0054] The fourth aspect embodiment of the present disclosure proposes a non-transitory computer-readable storage medium storing computer instructions, characterized in that the computer instructions are used to enable a computer to execute the method in the first aspect embodiment of the present disclosure.

[0055] The fifth aspect embodiment of the present disclosure proposes a computer program product, characterized in that it includes a computer program, and when the computer program is executed by a processor, it implements any method in the first aspect embodiment of the present disclosure.

[0056] In summary, according to the container resource management method proposed in the present disclosure, the stock resources of each node device of the service node are scanned to construct a resource topology model. The stock resources include at least one of the CPU, memory, GPU, and I / O devices, providing current resource data for resource management; based on the resource topology model, according to the access performance parameters between the resources in the service node, the cost factor of the cross-domain access of the Pod to each resource on the service node is determined, and the cross-domain access of the resources is evaluated; according to the QoS type of the resource allocation of the Pod on the service node, the optimal resource combination of the Pod in the resource topology model is determined by minimizing the objective function, wherein the objective function is constructed based on the cost factor, and the optimal resource combination of Pods of different QoS types is realized. By refining the resource allocation of the Pod, the access cost of the Pod node-level resource allocation is reduced, the access performance and the degree of refinement of the resource allocation are improved, and the matching and rationality of the use of the Pod node-level resource allocation and the flexibility of dynamic adjustment are realized.

[0057] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] The drawings herein are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the description are used to explain the principles of the present disclosure, and do not constitute improper limitations on the present disclosure.

[0059] Figure 1 A schematic diagram of the CPU hardware structure in a server in the related art;

[0060] Figure 2 A flowchart of a container resource management method according to an embodiment of the present disclosure;

[0061] Figure 3 A schematic diagram of a resource topology model according to an embodiment of the present disclosure;

[0062] Figure 4 A flowchart of an embodiment of the present disclosure that determines a cost factor for a Pod to perform cross-domain access to each resource on a service node based on a resource topology model and access performance parameters between resources in the service node;

[0063] Figure 5 It is a flowchart of an embodiment of the present disclosure that calculates performance parameters for cross-domain access between resources from lower-level resources to upper-level resources according to the hierarchical relationship of a resource topology model;

[0064] Figure 6A flowchart of an embodiment of the present disclosure for counting cost factors of cross-domain access of Pods on service nodes based on upper-layer resources, lower-layer resources and performance parameters;

[0065] Figure 7 This is a flowchart of an embodiment of the present disclosure for determining the optimal resource combination of a Pod in a resource topology model by minimizing an objective function according to the QoS type of resource allocation of the Pod on a service node;

[0066] Figure 8 A flowchart of an embodiment of the present disclosure that minimizes a first objective function based on preset constraints and QoS types to determine a first optimal solution for an optimal resource combination;

[0067] Fig. 9 This is a flow chart of allocating resources to Pods according to QoS types based on a first optimal solution according to an embodiment of the present disclosure;

[0068] Fig.10 This is a flow chart of allocating resources to Pods according to QoS types according to an embodiment of the present disclosure;

[0069] Fig.11 This is a flow chart of an embodiment of the present disclosure, according to a first optimal solution, for Pods to exclusively occupy target resources with a first priority;

[0070] Fig.12 A flowchart of a container resource management method according to an embodiment of the present disclosure;

[0071] Fig.13 A schematic diagram of the structure of a container resource management device according to an embodiment of the present disclosure;

[0072] Fig.14 is a block diagram of an electronic device for implementing the container resource management method disclosed in the present invention according to an exemplary embodiment;

[0073] Fig.15 It is a schematic diagram of the structure of the chip of the embodiment of the present disclosure. DETAILED DESCRIPTION

[0074] Embodiments of the present disclosure are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout identify the same or similar originals or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present disclosure, and should not be construed as limiting the present disclosure.

[0075] First, a brief introduction to the relevant terms in this disclosure is given:

[0076] Kubernetes: K8s for short, refers to a containerized application that manages multiple hosts in a cloud platform.

[0077] Container: A lightweight, portable application runtime environment that encapsulates an application and its dependencies. It encapsulates an application and its dependencies. Containers run in Pods, and all containers in a Pod share the same network and storage resources. Container technology makes application deployment and expansion more flexible and efficient.

[0078] Pod: refers to the basic scheduling unit in K8s, representing a collection of one or more containers that share the same network namespace and storage volume. Pod allows efficient communication and data sharing between containers and is usually used to deploy tightly coupled applications.

[0079] Node: refers to a physical or virtual machine in a K8s cluster that is responsible for running Pods. Each Node is managed by Kubelet, which is responsible for maintaining the status of the Node and ensuring that the Pod runs on the Node. The Node provides computing, storage, and network resources for Pods to use.

[0080] Containerd: In this disclosure, it refers to an open source container runtime tool that is mainly responsible for managing the entire life cycle of the container, including the startup, execution, and termination of the container. Containerd is designed to be simpler, more robust, and pluggable, and it can work with a variety of container image formats and storage systems. It is often used with Docker or other container solutions to provide a more stable and secure container management and execution environment, supports multiple operating systems, and is one of the core components of many container solutions, such as K8s, to achieve containerized application cluster management. One of the design goals of Containerd is to provide a standardized container runtime interface to make it easier to integrate into different systems and services.

[0081] Socket: In this disclosure, it refers to a slot that can physically accommodate one or more processor packages. Each processor package may contain one or more dies. Sockets usually provide an interface with the motherboard and other system components and are the connection point between the processor and the motherboard. There are usually one or more sockets on the server motherboard.

[0082] Die: In this disclosure, it refers to a physical silicon chip on a single semiconductor chip, containing one or more processor cores. A die may contain multiple cores and cache structures. Each die can be regarded as a single processing unit. Usually multiple dies are encapsulated in a physical processor package.

[0083] Core: In this disclosure, it refers to the computing core of the processor, which is a processing unit that can execute instructions independently. Each Core has its own registers and L1 cache, and can independently perform computing tasks. Modern CPUs usually have multiple cores, which can process multiple tasks in parallel. Each Socket corresponds to a physical processor package. The physical processor package contains one or more Dies, and each Die contains one or more Cores.

[0084] NUMA: refers to a computer memory architecture that allows multiple processors to access local and remote memory. NUMA nodes are also called NUMA domains. Each NUMA usually corresponds to a NUMA node, but in some advanced systems, a socket may contain multiple NUMA nodes. In a typical NUMA node, each NUMA node contains one or more processors and their local memory. In this configuration, the number of sockets and NUMA nodes is usually one-to-one. In high-performance computing, properly configuring the relationship between Pods and NUMA nodes can significantly improve performance, especially in latency-sensitive applications.

[0085] Quality of Service (QoS): In this disclosure, it refers to the level of service quality that a network can provide when transmitting data. QoS manages the priority of network traffic to ensure that critical applications (such as voice and video conferencing) obtain sufficient bandwidth and priority processing. It usually includes multiple performance indicators, including bandwidth, latency, packet loss rate, and jitter, which together determine the quality and reliability of data transmission. QoS can be achieved through a service level agreement to ensure the service level specified by the network service provider in the contract. QoS is widely used in various network environments, including enterprise networks, data centers, cloud computing, and Internet services, especially in application scenarios that require reliability and real-time performance.

[0086] Figure 1 This is a schematic diagram of the CPU hardware structure in the server in the related art. As shown in the figure, the hardware structure of this server includes two sockets, each socket contains two dies, and each die contains four cores. This structure provides a hardware example of multi-core, multi-die parallel computing capabilities, which is a common CPU hardware architecture in modern servers.

[0087] In the related technologies, the resource scheduling strategy of the K8s platform and the granularity of the use of computing resources by programs running in containers are relatively coarse. The refined use and management of resources play a vital role in improving the utilization rate of data centers. In NUMA-architecture servers, in addition to the CPU, other external hardware such as graphics processing units (GPUs), field programmable gate arrays (FPGAs), and specific domain acceleration cards are also affected by the NUMA architecture and have similar characteristics to the CPU. At present, the container cloud platform's support for containerized applications on NUMA-architecture hardware is extremely imperfect. In the K8s platform, the control plane mainly selects the corresponding work nodes from the work nodes that meet the requirements to deploy containers based on whether the overall work nodes meet the container's requirements for CPU, memory and other resources. This will cause contention for memory access bandwidth after the application is deployed, affecting resource utilization and / or container work efficiency.

[0088] On server hardware, CPU cores, memory controllers, I / O devices and other peripherals together with the I / O bus hierarchy and CPU interconnection form a rather complex network. When these resources are combined and allocated to a workload, such as a Pod instance created by K8s, the performance of the task load running on the Pod will vary greatly due to different data transmission lines and efficiencies, and different degrees of coordination between resources. Different CPU cores are located in different architectural unit groups, and different groups have different access delays and bandwidths to each memory controller and I / O device. Generally, the hardware architecture on server nodes is relatively fixed. If it is not properly planned and reasonably allocated, it is likely to cause resource misalignment and workload performance degradation.

[0089] Currently, K8s has insufficient node-level resource management capabilities, and the hardware resources on the nodes are usually overly simplified. For example, all CPUs and memories on the nodes are processed uniformly without fine-grained distinction, and K8s's support for NUMA configuration on the nodes is quite limited.

[0090] There are also some NUMA node core binding strategies for virtual machines in related technologies, but most of them are relatively simple. If they are directly transplanted to container scenarios, the resource allocation is not refined enough and lacks the flexibility of dynamic adjustment, so they are not completely applicable to container scenarios.

[0091] The method proposed in this disclosure is applied to container resource management tasks, and its application has a wide range of scenarios. The technical solution of this proposal, that is, the container refined resource management method based on dynamic programming, can be widely used in multiple scenarios or fields, especially those environments with high requirements for resource utilization and service quality. The following are some possible application scenarios:

[0092] Cloud computing platform: In the data center of a cloud service provider, refined resource management can effectively allocate and optimize the resources of virtual machines and containers, improve overall resource utilization, and reduce operating costs.

[0093] Big data processing: For big data clusters that need to process large amounts of data, such as Hadoop and Spark, refined resource management can ensure that data processing tasks run efficiently and reduce resource waste.

[0094] Online services and e-commerce: For online services and e-commerce platforms that need to support high concurrent access, refined resource management can provide better service performance and ensure user experience.

[0095] Virtualized environment: In a virtualized environment, refined resource management can help allocate CPU, memory and other resources more reasonably and improve the performance and efficiency of virtual machines.

[0096] Artificial Intelligence and Machine Learning: In artificial intelligence and machine learning training tasks, refined resource management can optimize the allocation of GPUs and other computing resources and accelerate the model training process.

[0097] Internet of Things and Edge Computing: In Internet of Things (IoT) devices and edge computing scenarios, refined resource management can ensure that applications can run efficiently even in resource-constrained environments.

[0098] Game Servers: For online game servers, refined resource management can provide more stable game performance and reduce latency and lag.

[0099] Scientific research computing: In scientific research, refined resource management can ensure that high-performance computing tasks obtain the necessary resources and improve research efficiency.

[0100] Content Distribution Network: On the Content Distribution Network (CDN) nodes, refined resource management can improve caching and distribution efficiency and speed up content transmission.

[0101] Blockchain nodes: For nodes in a blockchain network, refined resource management can optimize resource consumption for transaction processing and consensus algorithms.

[0102] Container orchestration platform: On container orchestration platforms such as K8s, refined resource management can improve the efficiency and stability of container deployment.

[0103] Multi-tenant environment: In multi-tenant SaaS applications, refined resource management can ensure that each tenant can obtain fair and efficient resource allocation.

[0104] Disaster recovery and disaster recovery systems: In disaster recovery and disaster recovery systems, refined resource management can quickly adjust resource allocation to ensure the continuity of key services.

[0105] Energy and resource-intensive applications: In resource-intensive applications in industries such as energy and mining, refined resource management can optimize resource use and reduce costs.

[0106] Telecommunications network: At the core nodes of telecommunications networks, refined resource management can improve the processing power and service quality of network equipment.

[0107] Aerospace: In computing tasks in the aerospace field, refined resource management can ensure that critical tasks have sufficient computing resources.

[0108] Healthcare: In data analysis and processing in the healthcare field, refined resource management can provide the necessary computing power to support fast and accurate data analysis.

[0109] Financial transactions: In financial transaction systems, refined resource management can ensure high performance and low latency of the transaction system.

[0110] Educational technology: On online education platforms, refined resource management can provide stable video streaming and interactive experience.

[0111] Intelligent Transportation System: In the intelligent transportation management system, refined resource management can optimize traffic data processing and analysis.

[0112] These scenarios require effective management and optimization of hardware resources to provide better performance and higher resource utilization. Refined resource management can play an important role in these areas and help enterprises and organizations achieve their business goals. The application scenarios are not limited in the embodiments of the present disclosure.

[0113] The container resource management method provided by the present disclosure is described in detail below with reference to the accompanying drawings.

[0114] Figure 2 FIG. 1 is a flow chart of a container resource management method according to an embodiment of the present disclosure. Figure 2 In the embodiment shown, the execution subject of the method is a resource management plug-in extended by the containerd component, which can manage container resources at the runtime layer of the container runtime. The container resource management method includes:

[0115] Step 201, scan the stock resources of each node device of the service node and build a resource topology model, the stock resources include at least one of CPU, memory, GPU, and I / O device.

[0116] In this embodiment, the service node refers to the cloud server node in cloud computing, which is the first independent computing unit in the cloud computing infrastructure. In this disclosure, the service node is a physical server node. Node devices refer to physical hardware resources such as servers for processing data, storage devices for storing and processing massive data, and network devices for efficient transmission of user data. Stock resources refer to hardware resources that have not been occupied in each node device of the service node, such as CPU, memory, GPU, and I / O devices. The resource topology model refers to the physical layout of various hardware resources interconnected by transmission media, as well as the specific arrangement between members that constitute the network, including real physical connections and logical virtual arrangements, which reflects the distribution and connection status of hardware resources in cloud computing service nodes.

[0117] Scan the stock resources of each node device of the service node to obtain the occupancy status of all hardware resources in the service node, and use the unoccupied stock resources to build a resource topology model to facilitate the provision of hardware resources for the newly created Pod.

[0118] Preferably, the present disclosure uses the upper and lower resource management of the CPU in the server node as an example to illustrate the container resource management. The resource topology model established for the CPU includes CPU Core, Die, and Socket in sequence from the child node (lower resource) to the root node (upper resource).

[0119] Deploy containerd components on server nodes and start services. Load and run the resource management plug-in extended by containerd to modify or extend Pods and containers at different stages of their lifecycles to customize resources, thereby completing the refined management of hardware resources by Pods.

[0120] Figure 3 FIG. 1 is a schematic diagram of a resource topology model of an embodiment of the present disclosure. Figure 3As shown, on the service node, the topology awareness plug-in is loaded at the initial startup phase of the containerd service, the overall physical topology structure on the server node is globally scanned, an architecture diagram is constructed, and a global available resource architecture topology diagram is generated. For example, a typical resource access topology model of a server node is scanned as follows. The hardware resources of this service node are composed of two Sockets, Socket1 and Socket2. Each Socket node is composed of two Die nodes, and each Die node is composed of four CPU Cores. The CPU Core can be used as a lower-level resource, the Die can be used as an upper-level resource of the CPU Core, the Die can be used as a lower-level resource of the Socket, and the CPU Core can be used as a lower-level resource of the Die. Similarly, in the resource access topology model, CPU Core1, CPU Core2, CPU Core3, and CPU Core4 are lower-level nodes of Die1, and Die1 and Die2 are lower-level nodes of Socket1.

[0121] Step 202, based on the resource topology model and according to the access performance parameters between the resources in the service node, determine the cost factor of the cross-domain access of the Pod to the resources on the service node.

[0122] In this embodiment, the access performance parameters refer to the performance parameters of the resources in the service node, including processors, memory, storage, and networks, when accessing each other, including but not limited to parameters such as latency, throughput, bandwidth, error rate, jitter, resource utilization, elasticity, reliability, and scalability. Cross-domain access refers to the data exchange and communication between different nodes in the resource topology model, for example, in the same Die domain, CPU Core1 accesses CPU Core2, or in the same Socket domain, Die1 accesses Die2, or different Socket domains access each other. The cost factor refers to the additional cost of Pod accessing various resources (nodes) on the server node, which is used to measure the speed of data access between different nodes. The lower the cost factor, the faster the cross-domain access between resources and the higher the efficiency.

[0123] Step 203, according to the QoS type of resource allocation of the Pod on the service node, the optimal resource combination of the Pod in the resource topology model is determined by minimizing the objective function, wherein the objective function is constructed based on the cost factor.

[0124] In this embodiment, the objective function refers to the scoring function of the unreasonable use of resources of the service node, which includes the cost factor. QoS types include resource-sensitive, resource-sharing and resource-oversold types. The characteristics and resource allocation fine strategies corresponding to different QoS types are shown in Table 1 below:

[0125] Table 1 QoS level of Pod resource allocation on service nodes

[0126]

[0127] According to the QoS type of resource allocation of Pod on the service node, different optimal resource combinations can be determined, which are obtained by minimizing the objective function.

[0128] In summary, according to the container resource management method proposed in the present disclosure, the stock resources of each node device of the service node are scanned to construct a resource topology model. The stock resources include at least one of the CPU, memory, GPU, and I / O devices, providing current resource data for resource management; based on the resource topology model, according to the access performance parameters between the resources in the service node, the cost factor of the cross-domain access of the Pod to each resource on the service node is determined, and the cross-domain access of the resources is evaluated; according to the QoS type of the resource allocation of the Pod on the service node, the optimal resource combination of the Pod in the resource topology model is determined by minimizing the objective function, wherein the objective function is constructed based on the cost factor, and the optimal resource combination of Pods of different QoS types is realized. By refining the resource allocation of the Pod, the access cost of the Pod node-level resource allocation is reduced, the access performance and the refinement of the resource allocation are improved, and the matching and rationality of the use of the Pod node-level resource allocation and the flexibility of dynamic adjustment are realized.

[0129] Figure 4 This is a flowchart of an embodiment of the present disclosure that determines the cost factor of a Pod's cross-domain access to each resource on a service node based on a resource topology model and according to access performance parameters between resources in the service node. Figure 4 Yes Figure 2 Further description of step 202 is based on Figure 4 The embodiment shown comprises the following steps:

[0130] Step 401, matching available resources in the resource topology model according to the upper limit value of the target resource to be occupied by the Pod.

[0131] In this embodiment, the target resource refers to the hardware resources in the service node that are needed to deploy the Pod and run normally. The upper limit value of the target resources to be occupied by the Pod refers to the maximum value of the target resources used, that is, the maximum amount of hardware resources that meet the usage requirements of the Pod. The available resources in the resource topology model refer to the idle resources that can be allocated corresponding to the target resources in the service node. According to the upper limit value of the target resources to be occupied by the Pod, the available resources that will be used can be matched in each node of the resource topology model.

[0132] Step 402: If the available resources are less than the upper limit, the performance parameters for cross-domain access between resources are calculated from lower resources to upper resources according to the hierarchical relationship of the resource topology model.

[0133] In this embodiment, the upper-layer resources and the lower-layer resources are in a relative relationship in the resource topology model. The lower-layer resources are closer to the leaf nodes of the topology tree of the resource topology model, while the upper-layer resources are closer to the root nodes of the topology tree of the resource topology model relative to the lower-layer resources. The lower-layer resources refer to the basic units of the hardware resources, and the upper-layer resources refer to the resource set after the lower-layer resources of the hardware resources are logically or physically encapsulated and summarized. Based on the relative relationship between the upper-layer resources and the lower-layer resources, multi-level resources can also be extended. For example, the upper-layer resources and the lower-layer resources of the resource topology model can construct a three-layer resource model, for example, the first-layer resources, the second-layer resources and the third-layer resources, where the first-layer resources are the upper-layer resources of the second-layer resources, and the second-layer resources are the upper-layer resources of the third-layer resources. Similarly, the third-layer resources are the lower-layer resources of the second-layer resources, and the second-layer resources are the lower-layer resources of the first-layer resources. Therefore, the upper-level resources and lower-level resources of the resource topology model disclosed in the present invention can be expanded to a multi-level resource model. The levels of the resource topology model are not limited in the present invention. In order to clearly express the scheme of the present invention, preferably, the present invention uses a three-layer example to illustrate the resource topology model.

[0134] If the available resources in the resource topology model are less than the upper limit of the target resources to be occupied by the Pod, it means that the available resources are insufficient to ensure the occupation of the target resources of the Pod, and then it is necessary to use the idle resources of other domains to supplement the current shortage of available resources. According to the hierarchical relationship of the resource topology model, the performance parameters for cross-domain access between resources are calculated step by step from the lower-level resources to the upper-level resources, such as calculating the resource access delay, network bandwidth, access times and other parameters of different domains between resources at the same level.

[0135] Step 403: Based on the upper-layer resources, lower-layer resources, and performance parameters, the cost factor of the cross-domain access of the Pod on the service node is counted.

[0136] In this embodiment, according to the architecture of the upper and lower resources established by the resource topology model, and the performance parameters of cross-domain access of resources between each layer, the cost factor of cross-domain access of Pod on the service node can be statistically obtained. The statistics can be obtained directly through the resource manager of the cloud computing system, or can be tested in the resource topology model through the monitoring program.

[0137] For example, the yaml configuration file for a Pod in the service node has the following configuration information:

[0138] resources:

[0139] limits:

[0140] CPU: "2"

[0141] This configuration information shows that the current upper limit of the CPU usage of the Pod is 2. Compared with the available CPU Cores in the nodes of the topology tree of the resource topology model, if CPU resource access crosses the Core, the additional cost of resource access increases by the corresponding proportional unit cost_cross(CPU,Core), that is, the cost factor of CPU cross-Core domain access is increased.

[0142] For another example, a Pod's YAML configuration file has the following configuration information:

[0143] resources:

[0144] limits:

[0145] CPU: "1.5"

[0146] According to this configuration information, if you need to obtain an additional 0.5 CPU Core resource across the Core domain in comparison with the available CPU Cores in the nodes of the topology tree of the resource topology model, the additional cost of accessing the Pod resource will increase by 0.5 units of cost_cross(CPU,Core). The value of cost_cross is obtained by performing load testing through the resource manager or test program.

[0147] In this embodiment, by determining the cost factor of cross-domain access of the Pod on the service node, a reliable allocation basis is provided for allocating resources to the Pod, which helps to use the cost factor to select the resource (node) combination with the lowest cost.

[0148] Figure 5 The present invention is a flowchart of an embodiment of the present invention for calculating performance parameters for cross-domain access between resources from lower-level resources to upper-level resources according to the hierarchical relationship of a resource topology model. Figure 5 Yes Figure 4 Further description of step 402 is based on Figure 5 The embodiment shown comprises the following steps:

[0149] Step 501, obtain the first cross-domain access index between the basic hardware units in the lower-level resources, wherein the basic hardware unit includes any one of the core Core of the CPU, the dynamic random access memory DRAM, and the stream processing unit of the GPU, and the first cross-domain access index includes at least the number of accesses, the network bandwidth, and the access delay.

[0150] In this embodiment, the basic hardware unit refers to the basic processing unit in the cloud computing architecture, for example, the basic processing unit of the computing unit is the core Core of the CPU, the basic processing unit of the storage unit is the dynamic random access memory DRAM chip, and the basic processing unit of the image processing unit GPU is the stream processing unit. The basic hardware unit is any one of the Core, DRAM, and stream processing unit. The first cross-domain access index refers to the performance index of cross-domain access between basic hardware units. Preferably, the first cross-domain access index is the access index between different Cores of the CPU, including data such as access delay and network bandwidth between Cores. The first cross-domain access index can be represented by the above-mentioned cost_cross(CPU, Core).

[0151] Step 502: According to the number of lower-layer resources under the upper-layer resources and the first cross-domain access index, a second cross-domain access index between upper-layer resources is counted.

[0152] In this embodiment, the second cross-domain access index refers to the performance index of cross-domain access between upper-level resources in the resource topology model, including data such as access delay and network bandwidth. The second cross-domain access index is obtained by the number of lower-level resources directly subordinate to the upper-level resources and the first cross-domain access index. For example, it is obtained by cost_cross(CPU, Die) or cost_cross(memory, Die) across the Die domain. At this time, the Die domain is an upper-level resource relative to the Core domain. When it comes to the upper-level resources of the Die domain, that is, accessing resource devices across the Socket domain, it generally involves more I / O devices (device_X) in addition to the CPU and memory, etc. Some of these devices are directly located in a Socket domain, such as a GPU card. Some I / O devices have a high affinity with a specific Socket node, and communicate by connecting to the bus on the corresponding node. Cross-Socket domain access usually increases delay overhead. It is agreed here that the resource access cost corresponds to the increase of cost_cross(CPU, Socket), cost_cross(memory, Socket) and cost_cross(device_X, Socket).

[0153] For example, the second cross-domain access indicator

[0154] cost_resource=Σnum_cross(dev_type,arch)*cost_cross(dev_type,arch)

[0155] The resource type dev_type includes CPU, memory, graphics processing unit GPU, and other devices device_X. The domain (architecture) includes Core domain, Die domain, and Socket domain.

[0156] In the above formula, num_cross(dev_type,arch) is the number of cross-domain access resource devices, and the specific value of cost_cross(dev_type,arch) can be comprehensively evaluated by running benchmark load tasks in the early stage.

[0157] According to the topology tree of the resource topology model, it can be seen that the cross-Socket level > cross-Die level > cross-Core level. Therefore, when the CPU core resources in a Socket domain are insufficient, it is necessary to cross the Socket node to access the CPU core in another Socket node. The process also involves cross-Die and cross-Core. The agreed statistics cost_cross(CPU,Socket) value already includes the cost_cross(CPU,Die) and cost_cross(CPU,Core) involved, so there is no need to repeat the statistics. Similarly, when a CPU needs to cross the Die area, cost_cross(CPU,Die) also includes cost_cross(CPU,Core). The same applies to other resources.

[0158] Step 503: If the available resource matched by the target resource is a lower-layer resource, the first cross-domain access indicator is used as a performance parameter.

[0159] In this embodiment, in the resource topology model, if the available resource matched by the target resource is a lower-layer resource, it means that the target resource only uses the lower-layer resource for cross-domain access, and the first cross-domain access indicator is used as the performance parameter.

[0160] Step 504: If the available resource matched by the target resource is an upper-layer resource, the second cross-domain access indicator is used as a performance parameter.

[0161] In this embodiment, in the resource topology model, if the available resource matched by the target resource is an upper-layer resource, it means that the cross-domain access of the target resource is completed by crossing the upper-layer resource, and the second cross-domain access indicator is used as the performance parameter.

[0162] In this embodiment, according to the hierarchical relationship of the resource topology model, the performance parameters of cross-domain access between resources are calculated step by step from lower resources to upper resources, providing preparation for the calculation of cost factors between different (resource) nodes.

[0163] Figure 6This is a flowchart of an embodiment of the present disclosure that counts cost factors of cross-domain access of Pods on service nodes based on upper-layer resources, lower-layer resources and performance parameters. Figure 6 Yes Figure 2 The specific description of step 203 is based on Figure 6 The embodiment shown comprises the following steps:

[0164] Step 601: Determine a first cost factor for cross-domain access between lower-layer resources based on performance parameters.

[0165] In this embodiment, when the lower-layer resource is a basic hardware unit, the first cross-domain access index of the cross-domain access between the lower-layer resources can be used as the first cost factor. Since the first cross-domain access index is determined by the performance parameter, the first cost factor of the cross-domain access between the lower-layer resources can also be determined by the first cross-domain access index.

[0166] Step 602: Determine a second cost factor of an upper-layer resource according to the lower-layer resource and the first cost factor, wherein the lower-level node of the upper-layer resource in the resource topology model includes the lower-layer resource.

[0167] In this embodiment, the second cost factor refers to the access cost paid for cross-domain access between upper-layer resources. Since the lower-level nodes of the upper-layer resources in the resource topology model include lower-layer resources, the second cost factor of the upper-layer resources can be obtained according to the number of lower-layer resources accessed across domains and the first cost factor.

[0168] Step 603: Determine a cost factor according to the first cost factor and the number of upper-layer resources, the second cost factor and the number of lower-layer resources.

[0169] In this embodiment, according to the first cost factor and the number of lower-layer resources, and the second cost factor and the number of upper-layer resources, the second cross-domain access index obtained by the following formula can be used as the cost factor:

[0170] cost_resource=∑num_cross(dev_type,arch)*cost_cross(dev_type,arch)

[0171] This cost factor reflects the total cost of cross-domain access that can be satisfied by deploying the target resources of the Pod in the resource topology model, and can serve as a key basis for Pod resource allocation.

[0172] Figure 7 This is a flowchart of an embodiment of the present disclosure that determines the optimal resource combination of a Pod in a resource topology model by minimizing an objective function according to the QoS type of resource allocation of the Pod on a service node. Figure 7 Yes Figure 3 and Figure 2 The specific description of step 203 is based on Figure 7 The embodiment shown comprises the following steps:

[0173] Step 701 : determining a first objective function as an objective function according to a cost factor, the idleness of available resources, the Shannon entropy of the resource allocation ratio of each layer in a resource topology model, and a control factor.

[0174] In this embodiment, the idleness of available resources refers to the proportion of unoccupied hardware resources in the service node to all available resources, which indicates the vacancy rate of available resources. The Shannon entropy of the resource allocation ratio at each layer in the resource topology model refers to the degree of aggregation or correlation of the resources allocated to the target resources of the Pod in the node domain involved in the resource topology model. The control factor refers to the weight factor of the above idleness or Shannon entropy. The first objective function refers to a scoring function constructed by the cost factor, the idleness of available resources, the Shannon entropy of the resource allocation ratio at each layer and the control factor to measure the unreasonable resource allocation of the target resources of the Pod in the resource topology model. It can be expressed by the following formula:

[0175]

[0176] In the formula,

[0177] dev∈Device_set

[0178] dev_type∈{CPU,memory,GPU,device_X...}

[0179] arch∈{Core,Die,Socket}

[0180] The first objective function includes the total additional cost (cost factor) cost_resource of the pod's access to various resources on the server node; the resource utilization rate of the device resources on the server node allocated to the pod is:

[0181] This formula also refers to the idleness of a resource device, so is the resource utilization rate of the device resources. The idleness here is the ratio of the actual idle resources obtained by subtracting the applied resources apply (dev, arch) from the available resources avail (dev, arch) to the total available resource quota (dev, arch). The lower the idleness, the higher the utilization rate of the corresponding device resources after allocation; and the Shannon entropy formula, which is used to measure the degree of aggregation of the resources allocated by the Pod in the largest node domain involved in the resource topology. Multiply the sum of the idle balances of the Pod on each resource device used by the Shannon entropy value. Among them, the parameters W1 and W2 are the weights of the above two, and the value range is only [0, 100%], and W1 + W2 = 100%, which can be adjusted according to the actual needs of the business scenario (can be 0). f is a control factor, and the value range is [-1, 1]. This value comprehensively judges the unreasonable degree of resource utilization of the Pod. The lower the score, the more reasonable the resource allocation.

[0182] When using the Shannon entropy formula to calculate the degree of aggregation of resource allocation in the node domain involved in the resource topology model of the Pod, if the allocation of all resource devices by the Pod is limited to the Die domain and does not cross the Socket domain, it means that the higher the resource aggregation, the lower the Shannon entropy value. Count the CPU and memory device resource allocation ratios of the Pod in each Die domain respectively, and calculate the degree of aggregation. If the allocation of all resource devices by the Pod is not only limited to the Die domain, but also involves the higher-level Socket domain, calculate the allocation ratio of each resource in each Socket domain. Calculate the Shannon entropy value corresponding to each resource and take the average value. Multiply the idleness of the Pod on each resource device used by the Shannon entropy value to further measure the rationality of resource allocation.

[0183] Step 702: Based on preset constraints and QoS types, minimize the first objective function and determine a first optimal solution for the optimal resource combination.

[0184] In this embodiment, the preset constraint condition refers to the limitation of the use of each resource in the target resource required by the Pod in the available resources. The first optimal solution refers to the solution of the optimal resource combination determined from the resource topology model, which is composed of the nodes in the resource topology model. The first optimal solution is obtained by minimizing the first objective function.

[0185] In one implementation of this embodiment, the configuration information for the newly created Pod is as follows:

[0186]

[0187] For the maximum resource requirement specification {CPU: A, MEM: B, GPU: C, dev1: D...}, obtain and count the remaining available amount of each device resource on the node at the time of application.

[0188] The default constraints are:

[0189] A≤∑avail(CPU socket_i,die_j,core_k )

[0190] B≤∑avail(MEM socket_m,die_n )

[0191] C≤∑avail(GPU socket_m )

[0192] …

[0193] Avail is the available amount of resource devices (CPU, MEM, GPU, etc.) from different Socket and Die areas. Here, CPU, MEM, GPU, etc. are all from the collection of all devices on the server node:

[0194] CPU socket_i,die_j,core_k ,MEM socket_m,die_n ,GPU socket_m ∈Device_set

[0195]

[0196] Step 703: If the number of the first optimal solution is equal to 1, resources are allocated to the Pod according to the QoS type based on the first optimal solution.

[0197] In this embodiment, if the number of first optimal solutions obtained by minimizing the first objective function is 1, it means that the current first optimal solution is the optimal combination for allocating resources to the Pod. Resources can be directly allocated to the Pod according to the Qos type based on the first optimal solution.

[0198] Step 704, if the number of the first optimal solutions is greater than or equal to 2, then according to the priority order, traverse the preset objective function group, and minimize each objective function in the preset objective function group to solve the second optimal solution, until the number of the second optimal solutions converges to one, then based on the second optimal solution, allocate resources to the Pod according to the Qos type, where the priority order is that the cross-domain access priority of the lower-level resources is higher than the cross-domain access priority of the upper-level resources.

[0199] In this embodiment, the priority order refers to the priority of cross-domain access. The cross-domain access priority of the lower-layer resources is higher than the cross-domain access priority of the upper-layer resources. Since the lower-layer resources have higher access bandwidth and lower access latency, the lower-layer resources are preferentially used for cross-domain access. The preset objective function group refers to the objective functions of multiple configuration resources constructed in order to further determine the optimal resource combination when the number of the first optimal solution is not unique. The second optimal solution refers to the unique and optimal resource allocation scheme obtained by using the objective function in the preset objective function group. If the number of the first optimal solutions is greater than or equal to 2, it means that the current resource allocation scheme is not the optimal scheme, and the obtained resource allocation is not unique. It is necessary to traverse the objective functions in the preset function group according to the priority order, and calculate the minimum value of each objective function in the preset function group as the second optimal solution until the number of the second optimal solutions converges to one. It means that the best resource allocation scheme is obtained at this time, so based on the second optimal solution obtained at this time, resources are allocated to the Pod according to the Qos type.

[0200] In one implementation of this embodiment, the preset function group includes the following objective functions:

[0201]

[0202] f_socket=W3*[∑num_cross(dev_type,socket)]+W4*[∑num_cross(dev_sensi_type,socket)]

[0203] f_die=W3*[∑num_cross(dev_type,die)]+W4*[∑num_cross(dev_sensi_type,die)]

[0204] f_core=W3*[∑num_cross(dev_type,core)]+W4*[∑num_cross(dev_sensi_type,core)]

[0205] Among them, dev_type∈{CPU,memory,GPU,device_X...},

[0206] For the f_apply function, the apply() function is used to obtain the maximum occupancy of each resource applied by the Pod; avail() obtains the resource share of each resource device before the Pod occupies it. dev_sensi is a resource-sensitive device. The weights W3 and W4 have a value range of [0,100%], W3+W4=100%. If the Pod's Qos type is dedicated_resource, priority is given to the sufficiency of its sensitive devices. Adjust the W4 weight to a larger value. For other Qos types, more attention is paid to the sufficiency of all devices. Adjust the W3 weight to a larger value. Since sensitive devices are included in all devices, if there is no preference for any resource device, W3 can be set to 100% and W4 to 0%.

[0207] If f_apply still has multiple sets of solutions, then according to the principle of locality, in order to improve performance, priority is given to satisfying fewer cross-domain access situations at higher levels.

[0208] First, ensure that the number of cross-Socket domains accessed by the pod is minimal, that is, minimize f_Socket. For the f_Socket function, dev_sensi_type is the sensitive resource type for the Pod with a Qos level of dedicated_resource. The weights W3 and W4 are the same as above.

[0209] Secondly, ensure that the number of cross-Die domains is minimal and minimize f_Die.

[0210] Furthermore, ensure that the number of cross-Core domains is minimal and minimize f_Core.

[0211] If you need to consider the different resource types and QoS requirements for different services carried by pods, and make complementary combinations to more effectively improve resource utilization, you can further refine management based on the above algorithm. For example, online services carried by pods are more concerned with CPU latency, while offline services are more concerned with memory and other devices. When allocating these two types of pods, you can first limit the collection range of Device_set to a fixed Socket, or even the Die area for the first round of allocation. If no combination can be found, expand the collection range of Device_set to adjacent areas for a second round of allocation until a suitable combination is found.

[0212] In addition, the entire collection of Device_set can be classified into several groups. Each group is allocated to Pods that bear a fixed type of workload. For each group of resource allocation, the above dynamic allocation algorithm is used to solve the optimal combination to further reduce the noisy neighbor problem.

[0213] In this embodiment, by minimizing the objective function, an optimal solution is obtained for the resource allocation of the Pod, accurate resource allocation is achieved, and the utilization rate of hardware resources is improved.

[0214] Figure 8 The present invention is a flowchart of an embodiment of the present invention for minimizing a first objective function based on preset constraints and QoS types and determining a first optimal solution for an optimal resource combination. Figure 8 Yes Figure 7 The specific description of step 702 is based on Figure 8 The embodiment shown comprises the following steps:

[0215] Step 801: If the QoS type is resource-sensitive, the control factor is set to a positive value, and the first objective function is minimized to obtain a first optimal solution.

[0216] In this embodiment, if the Qos type is resource-sensitive, it means that the Pod to be allocated resources needs to monopolize the available resources. Set the control factor in the first objective function to a positive value (the size is determined according to the degree of resource aggregation), so as to positively associate the resources, increase the difficulty of minimizing the value of the first objective function, and ensure that the first objective function can obtain the first optimal solution, so that the hardware resources determined by the first optimal solution are exclusively occupied by the Pod. If the resource allocation of a Pod is more discrete and evenly distributed in certain domains, the Shannon entropy value is higher; and the higher the utilization rate of the allocated equipment, the more difficult it is to ensure the performance and isolation of the equipment for the exclusive Qos type of the resource-sensitive Pod. Therefore, the first objective function resource_unreasonable_use_score calculated in the end has a higher unreasonable resource use score, indicating that the resource allocation is more unreasonable. On the contrary, the more concentrated the resource allocation of a Pod is in a certain domain, the lower the Shannon entropy value, the lower the utilization rate of the concentrated equipment, the better the performance and isolation can be guaranteed, and the first objective function resource_unreasonable_use_score calculated in the end has a lower unreasonable resource use score, indicating that the resource allocation is more reasonable.

[0217] In some implementations of this embodiment, if the resource allocation of a Pod is more discrete and evenly distributed in certain domains, the Shannon entropy value is higher; and the higher the utilization rate of the allocated equipment, the more difficult it is to ensure the performance and isolation of the equipment for the resource-sensitive Pod that exclusively occupies available resources. Therefore, the first objective function resource_unreasonable_use_score is finally calculated. The higher the unreasonable resource use score is, the more unreasonable the resource allocation is. On the contrary, the more concentrated the resource allocation of a Pod is in certain domains, the lower the Shannon entropy value is; the lower the utilization rate of the concentrated equipment is, the better the performance and isolation can be guaranteed. The first objective function resource_unreasonable_use_score is finally calculated. The unreasonable resource use score is lower, indicating that the resource allocation is more reasonable. For example, a pod allocates resources concentrated in the same Socket domain, and its own resource allocation scheme is more reasonable, but the calculated Shannon entropy value is 0, and the multiplication result is 0, which means that in this case, there is no need to consider the utilization rate of resources on a single Socket node. The first objective function resource_unreasonable_use_score is finally calculated. The unreasonable resource use score is lower, which also confirms that the rationality of resource allocation is higher. Suitable for evaluating the rationality of Pods whose QoS is resource-sensitive.

[0218] Step 802: If the QoS type is resource sharing or resource overbooking, the control factor is set to a negative value, and the first objective function is minimized to obtain a first optimal solution.

[0219] In this embodiment, if the QoS type is resource sharing or resource oversale, the control factor is set to a negative value (the size is determined according to the degree of dispersion of resource allocation), and the resources are reversely associated. Reduce the difficulty of minimizing the value of the first objective function, making it easier to meet the allocation conditions. For example, the more evenly the Pod's allocated resources are, the higher the Shannon entropy value is, and the higher the resource utilization rate is. The higher the result of multiplying the utilization rate of the Pod on each resource device used by the Shannon entropy value is, the lower the final result of the unreasonable resource utilization score is, indicating that the rationality is higher.

[0220] In this embodiment, according to the preset constraints and the QoS type of the Pod, by minimizing the first objective function, the first optimal solution of the optimal resource combination is determined in the resource topology model, the optimal allocation of Pod target resources is achieved, and the resource utilization and resource usage granularity and precision are improved.

[0221] Fig. 9 This is a flowchart of allocating resources to Pods according to QoS types based on a first optimal solution according to an embodiment of the present disclosure. Fig. 9 Yes Figure 7 The specific description of step 703 is based on Fig. 9 The embodiment shown comprises the following steps:

[0222] Step 901: If the QoS type is resource-sensitive, the target resource is exclusively occupied by the Pod with the first priority according to the first optimal solution.

[0223] In this embodiment, the first priority refers to the priority of allocating resources to resource-sensitive Pods. If the QoS type of the Pod is resource-sensitive, then according to the first optimal solution, the first priority is used to exclusively occupy the target resource for the Pod.

[0224] Step 902: If the QoS type is resource sharing, a portion of the target resources is allocated to the Pod with the second priority according to the first optimal solution.

[0225] In this embodiment, the second priority refers to the priority of allocating resources to resource-sharing Pods. If the QoS type of the Pod is resource-sharing, then according to the first optimal solution, a portion of the target resources is allocated to the Pod with the second priority, that is, sharing resources with other Pods.

[0226] Step 903: If the QoS type is resource oversale type, then according to the first optimal solution, the target resources are recovered for the Pod with the third priority, wherein the priorities of the first priority, the second priority and the third priority decrease in sequence.

[0227] In this embodiment, the third priority refers to the priority of allocating resources to the resource oversold Pod. If the QoS type of the Pod is the resource oversold type, it means that the available resources provided for the target resource are sufficient. Then, according to the first optimal solution, the target resource is reclaimed for the Pod with the third priority. Among them, the priority levels of the first priority, the second priority and the third priority decrease in sequence.

[0228] In this embodiment, according to the first optimal solution of resource allocation obtained, resources are allocated according to different QoS types, thereby realizing personalized resource allocation for different Pod types and improving the matching degree between hardware resources and Pods.

[0229] In one embodiment of the present disclosure, for the first objective function,

[0230] (1) For Pods with a Qos level of Shared_resource, the values ​​of w1 and w2 are not set to 0. The values ​​of w1 and w2 can be set to be roughly equal, taking into account the resource access cost, resource device dispersion and utilization rate. The corresponding apply resource application function is:

[0231] apply(dev,arch)=limits_pod_resource(dev,arch)

[0232] Among them, Limit_pod_resource is the maximum limit resource quota applied for by the Pod.

[0233] (2) For Pods with a Qos level of Reclaimed_resource, w1 and w2 are not set to 0, and w2 is set to be higher than w1. Due to the low priority, resource dispersion and utilization are given priority, and resource access cost is less considered. The apply resource application function is:

[0234] apply(dev,arch)=requests_pod_resource(dev,arch)

[0235] Among them, requests_pod_resource is the minimum resource quota requested by the Pod.

[0236] In the above two cases, solving the first priority objective function can basically obtain the optimal solution, that is, the optimal resource device allocation combination for Pod allocation.

[0237] (3) For a Pod with a Qos level of Dedicated_resource, the apply resource application function is:

[0238] apply(dev,arch)=limits_pod_resource(dev,arch)

[0239] As needed, consider setting w1 higher and w2 lower, giving priority to resource access cost and ensuring resource access quality, and secondarily considering resource utilization.

[0240] Fig.10 The present invention is a flowchart of allocating resources to Pods according to QoS types according to an embodiment of the present invention. Fig.10 Yes Figure 7 The specific description of step 704 is based on Fig.10 The embodiment shown comprises the following steps:

[0241] Step 1001: Determine a first ratio according to the applied resources and available resources of the Pod.

[0242] In this embodiment, the applied resources of the Pod refer to the resources applied for the Pod in the service node according to the usage of the target resources. The first ratio refers to the ratio of the applied resources to the available resources. The larger the first ratio value, the fewer the actual available resources, that is, the fewer resources can be allocated to the Pod.

[0243] Step 1002: Determine a second ratio according to the applied similar resources and available similar resources of the Pod.

[0244] In this embodiment, the applied similar resources of the Pod refer to the hardware resources in the applied resources that belong to the same predefined resource set. The hardware resources are similar. For example, the CPU cores between two processors of different models have the same or similar computing units. Available similar resources refer to similar resources that have not been used on the service node. The second ratio refers to the ratio of the applied similar resources to the available similar resources of the Pod. The larger the second ratio value, the fewer similar resources are actually available, that is, the fewer similar resources can be allocated to the Pod.

[0245] Step 1003: Determine a second objective function based on the first ratio and the second ratio, where the second objective function belongs to a preset objective function group.

[0246] In this embodiment, the second objective function refers to an objective function constructed by using the first ratio and the second ratio to further determine a unique optimal solution based on multiple first optimal solutions. The second objective function is the f_apply function in the above-mentioned preset objective function group.

[0247] Step 1004, according to the QoS type, adjust the weight parameters of the first ratio and the second ratio to minimize the second objective function. If the number of optimal solutions obtained is one, the optimal solution is used as the second optimal solution, and resources are allocated to the Pod based on the second optimal solution.

[0248] In this embodiment, for the second objective function, according to the QoS type, the weight parameters of the first ratio and the second ratio are adjusted to minimize the second objective function. If only one optimal solution is obtained, the optimal solution is used as the second optimal solution. Then, based on the second optimal solution, resources are allocated to the Pod according to the resource topology model.

[0249] Step 1005, if the number of optimal solutions obtained is greater than or equal to two, the number of cross-domain accesses of the lower-level resources or the upper-level resources is determined based on the order from the child node to the root node of the resource topology model, and the resources of the node with the smallest number of cross-domain accesses are allocated to the Pod.

[0250] In this embodiment, if the number of optimal solutions obtained in the previous step is greater than or equal to two, then based on the order from child nodes to root nodes of the resource topology model, the number of cross-domain accesses of lower-level resources or upper-level resources is counted, and the resources of the node with the least cross-domain access are allocated to the Pod.

[0251] In this embodiment, according to the priority order, the objective functions in the preset objective function group are traversed, and each objective function in the preset objective function group is minimized to solve the second optimal solution until the number of second optimal solutions converges to one. Then, based on the second optimal solution, resources are allocated to the Pod according to the Qos type, thereby ensuring that when the first optimal solution is not unique, resource allocation optimization can be continuously performed, a unique and optimal resource allocation plan is determined, and the precision of resource allocation and resource utilization are improved.

[0252] Fig.11 The present invention is a flowchart of an embodiment of the present invention in which a Pod exclusively occupies a target resource with a first priority according to a first optimal solution. Fig.11 Yes Fig. 9 The specific description of step 704 is based on Fig.10 The embodiment shown comprises the following steps:

[0253] Step 1101, obtaining the maximum amount resource of the target resource and the basic specification resource of the target resource.

[0254] In this embodiment, the maximum amount of resources refers to the maximum value of resources that the target resource will occupy. The basic specification resources refer to the smallest unit of resources that can be provided among the available resources. The maximum amount of resources and the basic specification resources of the target resource are obtained through system tools or programs.

[0255] Step 1102, determining a first quantity of basic specification resources that the Pod exclusively occupies the target resource according to the maximum quota resources and the basic specification resources.

[0256] In this embodiment, the first quantity refers to the number of basic specification resources that will be used when the Pod exclusively occupies the target resource. The first quantity of basic specification resources that the Pod exclusively occupies the target resource can be obtained by performing a quotient operation based on the maximum quota resource and the basic specification resource.

[0257] Step 1103: round up the first quantity to obtain a target quantity, and use the target quantity of basic specification resources as the target resources exclusively occupied by the Pod.

[0258] In this embodiment, the target quantity refers to the quantity of basic specification resources required to ensure that the Pod exclusively occupies the target resources and obtains independent, safe and sufficient resources. The target quantity can be obtained by rounding up the first quantity.

[0259] In one implementation of this embodiment,

[0260] For pods with a QoS level of Dedicated_resource, resource allocation priority is higher, and exclusive device resources must be allocated to them. The number of exclusive devices required is:

[0261]

[0262] Then add the following constraints:

[0263]

[0264] dev∈Device_set

[0265] Among them, avail_num(dev) is the number of dev resource devices that can be exclusively occupied by different sockets, dies, and core areas. limit(dev) is the maximum / limited usage requirement of the Pod for the exclusive resource device. quota(dev) is the resource usage specification of the Pod's exclusive device, that is, the size of the basic specification resource.

[0266] In this embodiment, for Pods whose QoS type is resource-sensitive, according to the first optimal solution, the target resources are exclusively occupied by the Pod with the first priority, providing the Pod with safe, sufficient and independent hardware resources, thereby ensuring the safety and stability of the running tasks of the high-priority Pod.

[0267] Fig.12 The present invention is a flowchart of a container resource management method according to an embodiment of the present invention. Fig.12 It is used for existing Pods Figure 1 Supplementary description of the method for container resource management based on Fig.12 The embodiment shown comprises the following steps:

[0268] Step 1201: Obtain a target resource access cost value of a target resource model.

[0269] In this embodiment, the target resource model refers to the standard of the resource model designed for the existing Pods, and the target resource access cost value refers to the cost value of access between target resources predetermined in the target resource model.

[0270] Step 1202: monitor the actual resource access cost value of resource allocation of all existing Pods on the service node.

[0271] In this embodiment, the stock Pod refers to the Pod that has been deployed and run in the service node. The actual resource access cost value refers to the actual resource access cost of the stock Pod monitored during operation, which can be obtained from values ​​such as latency and bandwidth.

[0272] Step 1203: Based on the actual resource access cost value and the target resource access cost value, the additional access cost between each Pod is traversed on the service node through a greedy algorithm.

[0273] In this embodiment, the additional access cost refers to the additional cost caused by cross-domain access when each Pod accesses each other. i ) and the target resource access cost value cost_resource_ideal(pod i ) and uses a greedy algorithm to traverse the additional access costs between all existing Pods on the service node.

[0274] Step 1204: Count the number of target Pods in the service node that satisfy an additional access cost greater than or equal to a preset threshold as a second number.

[0275] In this embodiment, the preset threshold refers to a value that measures the larger additional access cost. The second number refers to the number of target Pods in the service node that meet the additional access cost that meets the preset threshold. The number of target Pods in the service node that meet the additional access cost greater than or equal to the preset threshold is counted.

[0276] Step 1205: If the second number exceeds the preset ratio, based on the resource topology model and according to the access performance parameters between the resources in the target Pod, determine the cost factor for the target Pod to perform cross-domain access to each resource on the service node.

[0277] In this embodiment, the preset ratio refers to a value that measures the proportion of Pods with larger additional access costs in the existing Pods. If the second number exceeds the preset ratio, then according to the resource topology model, the access performance parameters between the various resources in the target Pod that needs to reallocate resources are counted to determine the cost factor for the target Pod to perform cross-domain access to each resource on the service node. The method for determining the cost factor here is consistent with the method for determining the cost factor described above in the present disclosure, and will not be repeated here.

[0278] Step 1206, according to the QoS type of resource allocation of the target Pod on the service node, determine the optimal resource combination of the target Pod in the resource topology model by minimizing the objective function, wherein the objective function is constructed based on the cost factor.

[0279] In this embodiment, according to the QoS type of resource allocation of the target Pod on the service node, the optimal resource combination of the target Pod in the resource topology model is determined by minimizing the objective function. The objective function is constructed based on the cost factor. The specific resource allocation details here are consistent with the method used when creating a new Pod, and will not be repeated here.

[0280] In one implementation of this embodiment, in the ideal node hardware resource model scenario, the additional total cost of resource access for each pod is cost_resource_ideal, and the calculation is:

[0281] Gap(pod i )=|cost_resource(pod i )-cost_resource_ideal(pod i )|

[0282] When it is found that the Gap value (additional access cost) of a server node exceeds a certain threshold, it means that the resource allocation of the pod on the current node is unreasonable and needs to be re-planned, designed and loaded with the relevant plug-in for dynamic resource adjustment of the calling node. You can refer to the method of fine-tuning resources for newly created Pods in the above solution, and adjust the resource allocation plan for pods with higher Gap values ​​one by one.

[0283] In this embodiment, for the typical scenario of misaligned cross-domain access, such as Pod1 accessing Core1 in Pod2 and Pod2 accessing Core2 in Pod1, the existing Pods are actively monitored and regulated to the pre-designed ideal state to efficiently allocate resources. This avoids the occurrence of unreasonable cross-domain access scenarios such as misaligned cross-domain access and improves the rationality of Pod node-level resource allocation and use.

[0284] In addition, the resource adjustment plug-in can be extended to call some system kernel-level cleanup mechanisms to promptly clean up and release redundant processes in the system and actively release process caches. For example, the ptmalloc memory allocator used by glibc can actively call malloc_trim to reduce the process cache. In addition, the mem.low soft limit value is set for high-priority Pods through cgroup kernel parameters. When the memory is lower than the low watermark limit value, try to reclaim the memory of other processes to ensure resource supply.

[0285] The container resource management method proposed in the embodiment of the present disclosure scans the stock resources of each node device of the service node and constructs a resource topology model. The stock resources include at least one of CPU, memory, GPU, and I / O devices, providing current resource data for resource management; based on the resource topology model, according to the access performance parameters between the resources in the service node, the cost factor of the cross-domain access of the Pod to each resource on the service node is determined, and the cross-domain access of the resource is evaluated; according to the QoS type of the resource allocation of the Pod on the service node, the optimal resource combination of the Pod in the resource topology model is determined by minimizing the objective function, wherein the objective function is constructed based on the cost factor, and the optimal resource combination of Pods of different QoS types is realized. By refining the resource allocation of the Pod, the access cost of the Pod node-level resource allocation is reduced, the access performance and the refinement of the resource allocation are improved, and the matching and rationality of the use of the Pod node-level resource allocation and the flexibility of dynamic adjustment are realized.

[0286] Corresponding to the methods provided in the above-mentioned embodiments, the present disclosure also provides a container resource management device. Since the device provided in the embodiment of the present disclosure corresponds to the methods provided in the above-mentioned embodiments, the implementation method of the method is also applicable to the device provided in this embodiment and will not be described in detail in this embodiment.

[0287] Fig.13 FIG. 1 is a schematic diagram of the structure of a container resource management device 1300 according to an embodiment of the present disclosure. Fig.13 As shown, the container resource management device includes:

[0288] A topology model building module 1310 is used to scan the stock resources of each node device of the service node and build a resource topology model, where the stock resources include at least one of a CPU, a memory, a GPU, and an I / O device;

[0289] The access cost determination module 1320 is used to determine the cost factor of the cross-domain access of the Pod to each resource on the service node based on the resource topology model and the access performance parameters between the resources in the service node;

[0290] The resource allocation module 1330 is used to determine the optimal resource combination of the Pod in the resource topology model by minimizing the objective function according to the QoS type of resource allocation of the Pod on the service node, wherein the objective function is constructed based on the cost factor.

[0291] In some embodiments, the access cost determination module 1320 is used to:

[0292] Match the available resources in the resource topology model according to the upper limit of the target resources to be occupied by the Pod;

[0293] If the available resources are less than the upper limit, the performance parameters for cross-domain access between resources are calculated from the lower resources to the upper resources according to the hierarchical relationship of the resource topology model;

[0294] Based on upper-layer resources, lower-layer resources, and performance parameters, calculate the cost factor of cross-domain access of Pods on service nodes.

[0295] In some embodiments, the access cost determination module 1320 calculates the performance parameters of cross-domain access between resources from lower-level resources to upper-level resources in the following manner according to the hierarchical relationship of the resource topology model:

[0296] Obtaining a first cross-domain access indicator between basic hardware units in the lower-layer resources, wherein the basic hardware unit includes any one of a CPU core Core, a dynamic random access memory DRAM, and a GPU stream processing unit, and the first cross-domain access indicator includes at least the number of accesses, the network bandwidth, and the access delay;

[0297] According to the number of lower-layer resources under the upper-layer resource and the first cross-domain access index, a second cross-domain access index between the upper-layer resources is counted;

[0298] If the available resource matched by the target resource is a lower-layer resource, the first cross-domain access indicator is used as a performance parameter;

[0299] If the available resource matched by the target resource is an upper-layer resource, the second cross-domain access indicator is used as a performance parameter.

[0300] In some embodiments, the access cost determination module 1320 uses the following method to calculate the cost factor of the cross-domain access of the Pod on the service node based on the upper-layer resources, lower-layer resources and performance parameters:

[0301] Determine a first cost factor for cross-domain access between lower-layer resources based on the performance parameter;

[0302] Determining a second cost factor of the upper-layer resource according to the lower-layer resource and the first cost factor, wherein the lower-level node of the upper-layer resource in the resource topology model includes the lower-layer resource;

[0303] The cost factor is determined according to the first cost factor and the number of upper-layer resources, the second cost factor and the number of lower-layer resources.

[0304] In some embodiments, the resource allocation module 1330 determines the optimal resource combination of the Pod in the resource topology model by minimizing the objective function according to the QoS type of resource allocation of the Pod on the service node in the following manner:

[0305] Determine a first objective function as an objective function according to a cost factor, an idleness of available resources, a Shannon entropy of a resource allocation ratio of each layer in a resource topology model, and a control factor;

[0306] Based on the preset constraints and QoS type, the first objective function is minimized to determine the first optimal solution of the optimal resource combination;

[0307] If the number of the first optimal solution is equal to 1, resources are allocated to the Pod based on the first optimal solution and the QoS type;

[0308] If the number of the first optimal solutions is greater than or equal to 2, the preset objective function group is traversed according to the priority order, and each objective function in the preset objective function group is minimized to solve the second optimal solution until the number of the second optimal solutions converges to one. Then, based on the second optimal solution, resources are allocated to the Pod according to the Qos type, where the priority order is that the cross-domain access priority of the lower-level resources is higher than the cross-domain access priority of the upper-level resources.

[0309] In some embodiments, the resource allocation module 1330 minimizes the first objective function based on preset constraints and QoS types to determine a first optimal solution for the optimal resource combination, including:

[0310] If the QoS type is resource-sensitive, the control factor is set to a positive value, and the first objective function is minimized to obtain the first optimal solution;

[0311] If the QoS type is resource sharing or resource overselling, the control factor is set to a negative value, and the first objective function is minimized to obtain the first optimal solution.

[0312] In some embodiments, the resource allocation module 1330 allocates resources to the Pod according to the QoS type based on the first optimal solution in the following manner:

[0313] If the QoS type is resource-sensitive, the first priority is used to exclusively occupy the target resource for the Pod according to the first optimal solution;

[0314] If the QoS type is resource sharing, a portion of the target resources is allocated to the Pod with the second priority according to the first optimal solution;

[0315] If the QoS type is resource oversale, the target resources are recovered for the Pod with the third priority according to the first optimal solution, wherein the priorities of the first priority, the second priority and the third priority decrease in sequence.

[0316] In some embodiments, the resource allocation module 1330 uses the following method to traverse the preset objective function group according to the priority order, and minimize each objective function in the preset objective function group to solve the second optimal solution until the number of second optimal solutions converges to one, and then allocates resources to the Pod according to the Qos type based on the second optimal solution:

[0317] Determine the first ratio based on the Pod's applied resources and available resources;

[0318] Determine the second ratio based on the applied similar resources and available similar resources of the Pod;

[0319] Based on the first ratio and the second ratio, determining a second objective function, the second objective function belonging to a preset objective function group;

[0320] According to the QoS type, adjust the weight parameters of the first ratio and the second ratio to minimize the second objective function. If the number of optimal solutions obtained is one, use the optimal solution as the second optimal solution, and allocate resources to the Pod based on the second optimal solution.

[0321] If the number of optimal solutions obtained is greater than or equal to two, the number of cross-domain accesses of lower-level resources or upper-level resources is determined based on the order from child nodes to root nodes in the resource topology model, and the resources of the node with the smallest number of cross-domain accesses are allocated to the Pod.

[0322] In some embodiments, the resource allocation module 1330 uses the following method to monopolize the target resource for the Pod with the first priority according to the first optimal solution:

[0323] Obtain the maximum amount of target resources and the basic specification resources of target resources;

[0324] Determine the first quantity of the basic specification resources that the Pod exclusively occupies the target resources according to the maximum quota resources and the basic specification resources;

[0325] The first quantity is rounded up to obtain the target quantity, and the target quantity of basic specification resources is used as the target resources exclusively occupied by the Pod.

[0326] In some embodiments, the device is further configured to:

[0327] Get the target resource access cost value of the target resource model;

[0328] Monitor the actual resource access cost value of resource allocation of all existing Pods on the service node;

[0329] Based on the actual resource access cost value and the target resource access cost value, the additional access cost between each Pod is traversed on the service node through a greedy algorithm;

[0330] The number of target Pods in the statistical service node that satisfy an additional access cost greater than or equal to a preset threshold is the second number;

[0331] If the second number exceeds the preset ratio, based on the resource topology model and according to the access performance parameters between the resources in the target Pod, determine the cost factor for the target Pod to perform cross-domain access to each resource on the service node;

[0332] According to the QoS type of resource allocation of the target Pod on the service node, the optimal resource combination of the target Pod in the resource topology model is determined by minimizing the objective function, where the objective function is constructed based on the cost factor.

[0333] In summary, through the container resource management device, the stock resources of each node device of the service node are scanned to construct a resource topology model, and the stock resources include at least one of the CPU, memory, GPU, and I / O devices; based on the resource topology model, according to the access performance parameters between the resources in the service node, the cost factor of the cross-domain access of the Pod to each resource on the service node is determined; according to the QoS type of resource allocation of the Pod on the service node, the optimal resource combination of the Pod in the resource topology model is determined by minimizing the objective function, wherein the objective function is constructed based on the cost factor. This device solves the problems of low access performance and low flexibility of dynamic adjustment caused by the insufficient refinement of the hardware resource allocation of the service node used by the Pod in the related technology, and allocates resources according to different business types of the Pod, thereby reducing the access cost of the Pod node-level resource allocation, improving the access performance and refinement of resource allocation, and achieving the matching and rationality of the Pod node-level resource allocation and the flexibility of dynamic adjustment.

[0334] In the above embodiments provided by the present disclosure, the methods and devices provided by the embodiments of the present disclosure are introduced. In order to implement the functions in the methods provided by the above embodiments of the present disclosure, the electronic device may include a hardware structure and a software module, and implement the above functions in the form of a hardware structure, a software module, or a hardware structure plus a software module. One of the above functions may be executed in the form of a hardware structure, a software module, or a hardware structure plus a software module.

[0335] Fig.14 It is a block diagram of an electronic device 1400 for implementing the container resource management method according to an exemplary embodiment.

[0336] For example, the electronic device 1400 may be a mobile phone, a computer, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0337] Reference Fig.14, the electronic device 1400 may include one or more of the following components: a processing component 1402 , a memory 1404 , a power component 1406 , a multimedia component 1408 , an audio component 1410 , an input / output (I / O) interface 1412 , a sensor component 1414 , and a communication component 1416 .

[0338] The processing component 1402 generally controls the overall operation of the electronic device 1400, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 1402 may include one or more processors 1420 to execute instructions to complete all or part of the steps of the above-mentioned method. In addition, the processing component 1402 may include one or more modules to facilitate the interaction between the processing component 1402 and other components. For example, the processing component 1402 may include a multimedia module to facilitate the interaction between the multimedia component 1408 and the processing component 1402.

[0339] The memory 1404 is configured to store various types of data to support operations on the electronic device 600. Examples of such data include instructions for any application or method operating on the electronic device 1400, contact data, phone book data, messages, pictures, videos, etc. The memory 1404 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0340] The power supply component 1406 provides power to the various components of the electronic device 1400. The power supply component 1406 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device 1400.

[0341] The multimedia component 1408 includes a screen that provides an output interface between the electronic device 1400 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 1408 includes a front camera and / or a rear camera. When the electronic device 1400 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0342] The audio component 1410 is configured to output and / or input audio signals. For example, the audio component 1410 includes a microphone (MIC), and when the electronic device 1400 is in an operation mode, such as a call mode, a recording mode, and a speech recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 1404 or sent via the communication component 1416. In some embodiments, the audio component 1410 also includes a speaker for outputting audio signals.

[0343] I / O interface 1412 provides an interface between processing component 1402 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: home button, volume button, start button, and lock button.

[0344] The sensor assembly 1414 includes one or more sensors for providing various aspects of status assessment for the electronic device 1400. For example, the sensor assembly 1414 can detect the open / closed state of the electronic device 1400, the relative positioning of components, such as the display and keypad of the electronic device 1400, and the sensor assembly 1414 can also detect the position change of the electronic device 1400 or a component of the electronic device 1400, the presence or absence of user contact with the electronic device 1400, the orientation or acceleration / deceleration of the electronic device 1400, and the temperature change of the electronic device 1400. The sensor assembly 1414 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 1414 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 1414 may also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0345] The communication component 1416 is configured to facilitate wired or wireless communication between the electronic device 1400 and other devices. The electronic device 1400 can access a wireless network based on a communication standard, such as WiFi, 2G or 3G, 4G LTE, 5G NR (NewRadio) or a combination thereof. In an exemplary embodiment, the communication component 1416 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 1416 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0346] In an exemplary embodiment, the electronic device 1400 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs, controllers, microcontrollers, microprocessors, or other electronic components to perform the above methods.

[0347] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 1404 including instructions, and the instructions can be executed by a processor 1420 of an electronic device 1400 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0348] The embodiments of the present disclosure further provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable a computer to execute the container resource management method described in the above embodiments of the present disclosure.

[0349] An embodiment of the present disclosure further provides a computer program product, including a computer program, which executes the container resource management method described in the above embodiment of the present disclosure when a processor executes the computer program.

[0350] Fig.15 is a schematic structural diagram of a chip 1500 for implementing the above container resource management method according to an exemplary embodiment.

[0351] Reference Fig.15The chip 1500 includes at least one communication interface 1501 and a processor 1502; the communication interface 1501 is used to receive a signal input to the chip 1500 or a signal output from the chip 1500, and the processor 1502 communicates with the communication interface 1501 and implements the container resource management method described in the above embodiment through a logic circuit or executing code instructions.

[0352] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. Instead, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0353] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "illustrative embodiments", "examples", "specific examples" or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiments or examples are included in at least one embodiment or example of the present disclosure. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0354] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code that includes one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present disclosure includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present disclosure belong.

[0355] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processing module, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or in combination with these instruction execution systems, devices or apparatuses. For the purposes of this specification, "computer-readable medium" can be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution system, device or apparatus, or in combination with these instruction execution systems, devices or apparatuses. More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection with one or more wires (control method), a portable computer disk box (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or otherwise processing in a suitable manner if necessary, and then stored in a computer memory.

[0356] It should be understood that the various parts of the embodiments of the present disclosure can be implemented by hardware, software, firmware or a combination thereof. In the above embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0357] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

[0358] In addition, each functional unit in each embodiment of the present disclosure may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium. The above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

[0359] Although the embodiments of the present disclosure have been shown and described above, it is to be understood that the above embodiments are exemplary and are not to be construed as limitations of the present disclosure. A person skilled in the art may make changes, modifications, substitutions and variations to the above embodiments within the scope of the present disclosure.

Claims

1. A container resource management method, characterized in that: The method comprises: Scan the stock resources of each node device of the service node and build a resource topology model, where the stock resources include at least one of a CPU, a memory, a GPU, and an I / O device; Based on the resource topology model, according to the access performance parameters between the resources in the service node, determine the cost factor of the cross-domain access of the Pod to the resources on the service node; According to the QoS type of resource allocation of the Pod on the service node, the optimal resource combination of the Pod in the resource topology model is determined by minimizing the objective function, wherein the objective function is constructed based on the cost factor.

2. The method according to claim 1, characterized in that The determining, based on the resource topology model and according to the access performance parameters between the resources in the service node, the cost factor of the cross-domain access of the resources by the Pod on the service node includes: Matching available resources in the resource topology model according to the upper limit value of the target resource to be occupied by the Pod; If the available resources are less than the upper limit, the performance parameters for cross-domain access between the resources are calculated step by step from lower resources to upper resources according to the hierarchical relationship of the resource topology model; Based on the upper-layer resources, the lower-layer resources, and the performance parameters, a cost factor of cross-domain access of the Pod on the service node is counted.

3. The method according to claim 2, characterized in that The step of calculating the performance parameters of cross-domain access between the resources from lower resources to upper resources according to the hierarchical relationship of the resource topology model includes: Obtaining a first cross-domain access indicator between basic hardware units in the lower-layer resources, wherein the basic hardware unit includes any one of a CPU core Core, a dynamic random access memory DRAM, and a GPU stream processing unit, and the first cross-domain access indicator includes at least the number of accesses, the network bandwidth, and the access delay; According to the number of the lower-layer resources under the upper-layer resources and the first cross-domain access indicator, counting a second cross-domain access indicator between the upper-layer resources; If the available resource matched by the target resource is the lower-layer resource, taking the first cross-domain access indicator as the performance parameter; If the available resource matched by the target resource is the upper-layer resource, the second cross-domain access indicator is used as the performance parameter.

4. The method according to claim 2, characterized in that: The counting of the cost factor of the cross-domain access of the Pod on the service node based on the upper-layer resources, the lower-layer resources, and the performance parameters includes: Determining a first cost factor for cross-domain access between the lower-layer resources according to the performance parameter; Determining a second cost factor of the upper-layer resource according to the lower-layer resource and the first cost factor, wherein the lower-level node of the upper-layer resource in the resource topology model includes the lower-layer resource; The cost factor is determined according to the first cost factor and the number of the upper-layer resources, the second cost factor and the number of the lower-layer resources.

5. The method according to claim 2, characterized in that: The determining, according to the QoS type of resource allocation of the Pod on the service node, the optimal resource combination of the Pod in the resource topology model by minimizing the objective function, includes: Determine a first objective function as the objective function according to the cost factor, the idleness of the available resources, the Shannon entropy of the resource allocation ratio of each layer in the resource topology model, and a control factor; Based on preset constraints and the QoS type, the first objective function is minimized to determine a first optimal solution for the optimal resource combination; If the number of the first optimal solutions is equal to 1, based on the first optimal solution, resources are allocated to the Pod according to the QoS type; If the number of the first optimal solutions is greater than or equal to 2, the preset objective function group is traversed according to the priority order, and each objective function in the preset objective function group is minimized to solve the second optimal solution until the number of the second optimal solutions converges to one, then based on the second optimal solution, resources are allocated to the Pod according to the Qos type, wherein the priority order is that the cross-domain access priority of the lower-layer resources is higher than the cross-domain access priority of the upper-layer resources.

6. The method according to claim 5, characterized in that The step of minimizing the first objective function based on the preset constraint condition and the QoS type and determining a first optimal solution for the optimal resource combination includes: If the QoS type is resource-sensitive, the control factor is set to a positive value, and the first objective function is minimized to obtain the first optimal solution; If the QoS type is resource sharing or resource overselling, the control factor is set to a negative value, and the first objective function is minimized to obtain the first optimal solution.

7. The method according to claim 5, characterized in that The allocating resources to the Pod based on the first optimal solution and according to the QoS type includes: If the QoS type is resource-sensitive, the target resource is exclusively occupied by the Pod with a first priority according to the first optimal solution; If the QoS type is resource sharing, a portion of the target resource is allocated to the Pod with a second priority according to the first optimal solution; If the QoS type is resource oversale type, the target resource is reclaimed for the Pod with the third priority according to the first optimal solution, wherein the priorities of the first priority, the second priority and the third priority decrease in sequence.

8. The method according to claim 5, characterized in that The step of traversing the preset objective function group according to the priority order and minimizing each objective function in the preset objective function group to solve the second optimal solution until the number of the second optimal solutions converges to one, and then allocating resources to the Pod according to the Qos type based on the second optimal solution, including: Determining a first ratio according to the applied resources of the Pod and the available resources; Determining a second ratio according to the applied similar resources and the available similar resources of the Pod; Determining a second objective function based on the first ratio and the second ratio, where the second objective function belongs to the preset objective function group; According to the QoS type, adjust the weight parameters of the first ratio and the second ratio to minimize the second objective function. If the number of optimal solutions obtained is one, use the optimal solution as the second optimal solution, and allocate resources to the Pod based on the second optimal solution. If the number of optimal solutions obtained is greater than or equal to two, the number of cross-domain accesses of the lower-layer resources or the upper-layer resources is determined based on the order from the child node to the root node of the resource topology model, and the resources of the node with the smallest cross-domain access number are allocated to the Pod.

9. The method according to claim 7, characterized in that: The step of monopolizing the target resource for the Pod with a first priority according to the first optimal solution includes: Acquire the maximum amount resource of the target resource and the basic specification resource of the target resource; Determine, according to the maximum amount resource and the basic specification resource, a first quantity of the basic specification resource that the Pod exclusively occupies the target resource; The first quantity is rounded up to obtain a target quantity, and the target quantity of the basic specification resources is used as the target resource exclusively occupied by the Pod.

10. The method according to claim 1, characterized in that The method further comprises: Get the target resource access cost value of the target resource model; Monitor the actual resource access cost value of resource allocation of all existing Pods on the service node; Based on the actual resource access cost value and the target resource access cost value, traversing the additional access cost between each Pod on the service node through a greedy algorithm; Counting the number of target Pods in the service node that satisfy the additional access cost greater than or equal to the preset threshold as a second number; If the second number exceeds a preset ratio, determining, based on the resource topology model and according to access performance parameters between resources in the target Pod, a cost factor for the target Pod to perform cross-domain access to the resources on the service node; According to the QoS type of resource allocation of the target Pod on the service node, the optimal resource combination of the target Pod in the resource topology model is determined by minimizing the objective function, wherein the objective function is constructed based on the cost factor.

11. A container resource management device, characterized in that: The device comprises: A construction module, used to scan the stock resources of each node device of the service node and build a resource topology model, wherein the stock resources include at least one of a CPU, a memory, a GPU, and an I / O device; An access cost determination module, used to determine a cost factor for a Pod to perform cross-domain access to each resource on the service node based on a resource topology model and access performance parameters between each resource in the service node; A resource allocation module is used to determine the optimal resource combination of the Pod in the resource topology model by minimizing an objective function according to the QoS type of resource allocation of the Pod on the service node, wherein the objective function is constructed based on the cost factor.

12. An electronic device, characterized in that: include: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 11.

13. A non-transitory computer-readable storage medium storing computer instructions, characterized in that: The computer instructions are used to cause the computer to execute the method according to any one of claims 1-11.

14. A computer program product, characterized in that The invention comprises a computer program which, when executed by a processor, implements the method according to any one of claims 1 to 11.

Images