A container resource optimization method based on micro-service architecture in a resource-constrained environment
By configuring resources in a microservice system, resource allocation is achieved, resource optimization is solved, and system stability and resource utilization are improved.
Patent Information
- Application Number
- CN202511526895.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-24
- Publication Date
- 2026-02-24
- Estimated Expiration
- 2045-10-24
AI Technical Summary
Kubernetes scheduling algorithms only consider CPU and memory resources when allocating resources, which leads to uneven resource allocation, lacks consideration for the diversity of Pod applications, causes node resource skew, may cause system response failures, and cannot optimize cluster performance degradation.
By performing link analysis on the microservice system, the dependencies between microservices are determined. Using adjacency matrix and system matrix calculations, resource allocation strategies are implemented based on link optimization to optimize the resource configuration of the microservice system.
It automates resource allocation, improves resource utilization, optimizes system stability, solves resource allocation problems, and enhances system operating efficiency.
Smart Images

Figure CN121000620B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of cloud computing and container resource management technology, specifically to a container resource optimization method based on a microservice architecture in a resource-constrained environment. Background Technology
[0002] In related technologies, cloud-native is a methodology for designing, building, and running applications in a cloud computing environment, emphasizing features such as containerization, microservice architecture, automated operations and maintenance, and continuous delivery. Currently, cloud-native technology is widely defined as allowing users to build and run flexible and scalable applications in various environments, including public, private, and hybrid clouds. Typical examples of this technology include declarative APIs, business meshes, containers, microservices, and immutable infrastructure. These technologies not only improve resource utilization efficiency and accelerate computing speed in cloud platforms, but also enable enterprises and research institutions to possess greater data processing capabilities, including real-time information processing, streaming data processing, batch processing, big data analytics discovery, random data analysis and search, and more big data analytics application models. Among these, container technology has significantly changed traditional virtualization methods. In traditional virtualization, each virtual machine requires its own operating system and applications, leading to low resource efficiency and high management complexity. Container technology, by utilizing operating system-level virtualization, packages applications into independent containers, making them more flexible, portable, and scalable. Simultaneously, the service models of cloud computing platforms are becoming increasingly diversified. Through virtualization technology, cloud computing platforms can provide various computing, application, storage, and business resources to all network users in an integrated business logic. It can be said that the core concept of cloud computing technology is virtualization.
[0003] However, traditional virtualization technologies still have many problems. For example, in a traditional virtualization environment, each virtual machine requires an independent operating system and resources, leading to resource waste and inefficiency. Because they need to share the computing resources of the same physical server, performance competition may occur between virtual machines, resulting in performance degradation. These problems make traditional virtualization technologies unsuitable in certain scenarios, especially in the era of cloud computing, where users' demands for more efficient, flexible, and secure services are growing. Therefore, new cloud computing technologies and service models (such as container technology, serverless architecture, and cloud-native architecture) are gradually replacing traditional virtualization technologies to meet the needs for faster, more efficient, and more secure services. The Linux kernel added control groups (cgroups). Using isolation technology allows the environment in which a service runs to remain relatively closed; this closed runtime environment is called a container. Container virtualization technology is known for its flexibility, lightweight nature, and rapid deployment. Unlike a single virtual machine, which can host multiple software or services, each container typically runs only a single software or service. Therefore, managing numerous servers and thousands of containers in a distributed cluster has become a pressing problem and a significant technical challenge.
[0004] To address the challenges of container management in clusters, container cluster management systems such as Kubernetes, Docker Swarm, and Portainer have emerged. They meet the need for cross-host container cluster management. Among them, Kubernetes is the most widely used and fastest-growing container cluster management system. It was open-sourced by Google, combining Google's years of cluster management experience and community innovation practices. Unlike Docker Swarm and Portainer, Kubernetes offers highly customizable services, allowing users to specify their own solutions based on their business needs.
[0005] A key feature of Kubernetes is container orchestration. The goal of container orchestration is to optimize the scheduling of multiple containers submitted online by users, improving performance to meet both user time constraints and cloud provider power consumption requirements. Kubernetes uses a budget strategy to filter Pods based on their resource limitations, and determines the optimal node by checking if the Pod's state and shared host network namespace are identical, thus achieving optimal budget allocation. Simultaneously, Kubernetes' optimization algorithm, through its designed functions, prioritizes the node with the highest scores in hardware resources such as memory and CPU as the node to run the Pod. If multiple nodes have the same score, a node is randomly selected as the current Pod's node. By using these two scheduling algorithms in combination, Kubernetes can meet the resource requirements for container scheduling in most scenarios.
[0006] However, the Kubernetes scheduling algorithm still has some shortcomings that need improvement. For example, the algorithm only considers CPU and memory resources when scheduling resources; using the same weight to calculate the scores of all nodes in the cluster can easily lead to node resource skew; and there is a risk that the application may experience complete system failure during a specific period. In addition, Kubernetes can only configure resources for initial deployment, and does not fully consider the issue of cluster performance degradation.
[0007] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of the present invention, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention
[0008] This invention provides a container resource optimization method based on microservice architecture in resource-constrained environments, and a computer program product that can effectively overcome the defects existing in the prior art.
[0009] Other features and advantages of the invention will become apparent from the following detailed description, or may be learned in part by practice of the invention.
[0010] According to a first aspect of the present invention, a method for optimizing container resources based on a microservice architecture in a resource-constrained environment is provided, the method comprising:
[0011] Perform link analysis on the current microservice system to determine the link relationships between related microservices; where link relationships describe the type of link between related microservices, including direct dependency relationships and indirect dependency relationships;
[0012] Based on the system architecture of the microservice system and the link relationships between related microservices, the adjacency matrix P and the system relation matrix A corresponding to the microservice system are determined. The adjacency matrix is used to describe the dependency relationships between microservices within the microservice system, and the system relation matrix A is used to describe the dependency relationship types between related microservices.
[0013] The explicit matrix E and implicit matrix I corresponding to the microservice system are calculated using the adjacency matrix P and the system relation matrix A. The explicit matrix E is used to represent the explicit dependencies between links in the microservice system and to describe the dependency strength of links with direct dependencies. The implicit matrix I is used to represent the implicit dependencies between links in the microservice system and to describe the dependency strength of links with indirect dependencies.
[0014] The total dependency strength of the links is calculated based on the explicit matrix E and the implicit matrix I, and the link priority is configured for each link based on the total dependency strength.
[0015] In response to resource allocation instructions under resource-constrained conditions, the target microservice instance is weighted based on link priority; and the target microservice instance is deployed as a Pod based on the reconfigured weight information.
[0016] In some exemplary implementations, link analysis is performed on the current microservice system to determine the link relationships between related microservices, including:
[0017] Obtain the microservices in the microserver system, as well as the links between related microservices;
[0018] Based on the association between each link and the first microservice, configure the two related links to have a direct dependency relationship; or
[0019] Based on the association between each link and the first or second microservice, the two links are configured to have an indirect dependency relationship; among them, the first microservice and the second microservice have a direct association relationship.
[0020] In some exemplary implementations, based on the system architecture of the microservice system and the link relationships between associated microservices, the adjacency matrix P and system relationship matrix A corresponding to the microservice system are determined, including:
[0021] Based on the dependencies between related microservices in a microservice system, construct an adjacency matrix P based on the microservices; and
[0022] Based on the dependencies between related microservices in the microservice system and the types of links between related microservices, construct a system relationship matrix A based on microservices and links.
[0023] In some exemplary implementations, the explicit matrix E and implicit matrix I corresponding to the microservice system are calculated using the adjacency matrix P and the system relation matrix A, including:
[0024] Calculate the explicit matrix E based on the system relation matrix A and its corresponding transpose matrix, including: ; where the off-diagonal elements in the explicit matrix E e ij Indicates a link i and links j The number of public services that provide information; and
[0025] Based on the system relation matrix A and its corresponding transpose matrix, and in conjunction with the adjacency matrix P, the implicit matrix I is calculated, including: ; where each matrix cell of implicit matrix I is defined as , where a and p are elements of the system correlation matrix A and adjacency matrix P, respectively.
[0026] In some exemplary implementations, the total dependency strength of the links is calculated based on the explicit matrix E and the implicit matrix I, and link priorities are configured for each link based on the total dependency strength, including:
[0027] The total dependency strength of the links is calculated based on the explicit matrix E and the implicit matrix I, including: Wherein, LDM is the total link dependency strength matrix, and the value of a cell in the matrix represents the dependency strength between two links; the dependency strength is proportional to the link priority.
[0028] Configure link priority for the two corresponding links based on dependency strength.
[0029] In some exemplary embodiments, the method further includes:
[0030] Based on the priority parameters of each link, configure the microservice priority with the same priority parameter for the microservice associated with that link.
[0031] In some exemplary implementations, in response to resource allocation indication information under resource-constrained conditions, weights are configured for the target microservice instance based on link priority; and Pods are deployed for the target microservice instance based on the reconfigured weight information, including:
[0032] In response to multiple Pod deployment instructions under resource-constrained conditions, the PriorityClasses scheduler is invoked to create a PriorityClasses resource list, priority weights are configured for the target microservice instance based on link priority, and Pods are deployed for the target microservice instance based on the reconfigured priority weights.
[0033] Each container instance in a Pod belongs to the same microservice.
[0034] In some exemplary implementations, in response to resource allocation indication information under resource-constrained conditions, weights are configured for the target microservice instance based on link priority; and Pods are deployed for the target microservice instance based on the reconfigured weight information, including:
[0035] In response to Pod migration instructions under resource-constrained conditions, obtain the corresponding migration resource consumption data and node available resource data; wherein, the available resource data includes the node's current remaining resources;
[0036] By combining migration resource consumption data and node available resource data, a container resource optimization model based on genetic algorithm is used to determine the resource allocation strategy;
[0037] Based on link priority, the target microservice instance is deployed to the corresponding node according to the resource configuration policy.
[0038] In some exemplary embodiments, the method further includes:
[0039] Get the current state of the microservice; where the microservice state includes: stateless service and stateful service;
[0040] Based on the user's custom parameters for the target microservice, the StatefulSet workload controller is invoked to execute the corresponding custom parameters on the microservice instance that is a stateful service.
[0041] According to a second aspect of the present invention, a computer program product is provided, on which a computer program is stored, and when the computer program is executed by a processor, it implements the above-described container resource optimization method based on microservice architecture in a resource-constrained environment.
[0042] According to a third aspect of the present invention, a storage medium is provided having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described container resource optimization method based on a microservice architecture in a resource-constrained environment.
[0043] According to a fourth aspect of the present invention, an electronic device is provided, comprising:
[0044] Processor; and
[0045] Memory for storing the executable instructions of the processor;
[0046] The processor is configured to implement the above-described container resource optimization method based on microservice architecture in a resource-constrained environment by executing the executable instructions.
[0047] The container resource optimization method based on a microservice architecture in a resource-constrained environment provided by embodiments of the present invention analyzes the dependencies between microservices, links, and between microservices and links within a microservice system, accurately identifying the dependency strength between links in the microservice system. This allows for accurate analysis of the relative priorities of links and microservices based on dependency strength, providing an effective basis for resource allocation under resource-constrained conditions. This ensures the rationality of container resource allocation and the stability of the system under resource-constrained conditions.
[0048] Furthermore, when configuring resources under resource constraints, the problem of container resource allocation under resource constraints is solved by reallocating the weights of microservice instances based on link priority. This optimizes the speed and quality of the traditional genetic algorithm's solution, ensures the stability of the entire cluster performance under resource constraints, and improves the utilization rate of cloud computing resources.
[0049] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description
[0050] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention. It is obvious that the drawings described below are merely some embodiments of the invention, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.
[0051] Figure 1 This illustration shows a schematic diagram of a container resource optimization method based on a microservice architecture in a resource-constrained environment, as an exemplary embodiment of the present invention.
[0052] Figure 2 The diagram illustrates a method flow for analyzing system architecture according to an exemplary embodiment of the present invention.
[0053] Figure 3 This diagram schematically illustrates a direct dependency relationship according to an exemplary embodiment of the present invention;
[0054] Figure 4 This diagram schematically illustrates an indirect dependency relationship according to an exemplary embodiment of the present invention.
[0055] Figure 5 The diagram illustrates a microservice system architecture according to an exemplary embodiment of the present invention.
[0056] Figure 6 The diagram illustrates an adjacency matrix according to an exemplary embodiment of the present invention.
[0057] Figure 7 This diagram schematically illustrates a system correlation matrix according to an exemplary embodiment of the present invention;
[0058] Figure 8 The diagram illustrates an explicit dependency matrix according to an exemplary embodiment of the present invention.
[0059] Figure 9 The diagram illustrates an implicit dependency matrix according to an exemplary embodiment of the present invention.
[0060] Figure 10 This diagram schematically illustrates a total link dependency matrix according to an exemplary embodiment of the present invention.
[0061] Figure 11 This diagram schematically illustrates an optimized system link according to an exemplary embodiment of the present invention;
[0062] Figure 12The diagram illustrates an exemplary embodiment of the present invention, showing four types of chromosome variation operations.
[0063] Figure 13 This schematic diagram illustrates the target values during the training process of various objective functions, as exemplified by an embodiment of the present invention.
[0064] Figure 14 The diagram illustrates the composition of an electronic device according to an exemplary embodiment of the present invention. Detailed Implementation
[0065] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that the invention will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0066] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.
[0067] In related technologies, the Kubernetes scheduling algorithm still has some shortcomings that need improvement. For example, the algorithm only considers CPU and memory resources when scheduling resources, lacking consideration for the diversity of Pod applications; using the same weight to calculate the scores of all nodes in the cluster can easily lead to node resource skew, and cannot guarantee that high-priority services will be satisfied when resources are scarce. Therefore, it may lead to situations where the system response completely fails during a specific period of time. In addition, Kubernetes can only configure resources for the initial deployment, without considering the minimization of resource consumption costs incurred after Pod application deployment, or the performance degradation of the cluster caused by a large number of scheduling operations.
[0068] To address the shortcomings and deficiencies of existing technologies, this example implementation provides a container resource optimization method based on a microservice architecture in a resource-constrained environment. (Reference) Figure 1 As shown, it specifically includes:
[0069] Step S11: Perform link analysis on the current microservice system to determine the link relationships between related microservices; wherein, the link relationship is used to describe the type of link between related microservices, including direct dependency relationship and indirect dependency relationship;
[0070] Step S12: Based on the system architecture of the microservice system and the link relationships between related microservices, determine the adjacency matrix P and system relationship matrix A corresponding to the microservice system; wherein, the adjacency matrix is used to describe the dependency relationships between each microservice in the microservice system; the system relationship matrix A is used to describe the dependency relationship types between related microservices.
[0071] Step S13: Calculate the explicit matrix E and implicit matrix I corresponding to the microservice system using the adjacency matrix P and the system relation matrix A; where the explicit matrix E is used to represent the explicit dependencies between links in the microservice system and to describe the dependency strength of links with direct dependencies; the implicit matrix I is used to represent the implicit dependencies between links in the microservice system and to describe the dependency strength of links with indirect dependencies.
[0072] Step S14: Calculate the total dependency strength of the links based on the explicit matrix E and the implicit matrix I, and configure link priorities for each link based on the total dependency strength;
[0073] Step S15: In response to resource allocation indication information under resource-constrained conditions, configure weights for the target microservice instance based on link priority; and deploy Pods for the target microservice instance based on the reconfigured weight information.
[0074] This invention provides a method for allocating resources required by containers under conditions where system response time is limited to a certain threshold and cluster resources are constrained, thereby improving the quality of software services and resource utilization in a cloud-native environment. A container resource optimization strategy based on a genetic algorithm is designed. The analysis of dependencies between microservice links includes microservice-to-microservice relationships, microservice-to-link relationships, and link-to-link relationships. By using DSM analysis technology, the dependency strength between links can be identified. Therefore, their relative priorities can be calculated based on their dependency strength. The highest priority chain in a microservice-based application is identified by calculating the dependency strength between microservice links using the MDD method. By designing a container resource optimization model based on a genetic algorithm, a reference is provided for solving the container resource allocation problem under resource-constrained conditions. The speed and quality of the traditional genetic algorithm's solution are optimized, ensuring the stability of the entire cluster performance under resource-constrained conditions and improving the utilization of cloud computing resources.
[0075] The following will describe in more detail each step of the container resource optimization method based on microservice architecture in a resource-constrained environment in this example embodiment, with reference to the accompanying drawings and embodiments.
[0076] For example, a primary goal of Kubernetes applications is to make containerized applications easier to deploy and manage. Kubernetes makes it very convenient to manage and manipulate API objects by using metadata fields. For instance, a tag selector can be used to select a set of API objects that meet specific criteria and perform batch operations on them. Furthermore, metadata can help administrators better understand and manage the various API objects across the entire Kubernetes cluster.
[0077] In a Kubernetes cluster, a Pod is the smallest deployable unit, containing one or more tightly coupled containers. A Pod provides a logical host concept, allowing multiple containers to share network and storage. A Node is a worker node in the cluster. Each Node is the host machine running Pods, providing compute and storage resources to support application execution. When a Pod is scheduled into the cluster, Kubernetes selects a suitable Node and assigns the Pod to it. A Pod can only run on one Node, but a Node can run multiple Pods simultaneously. Furthermore, a Pod can deploy one or more containers, each corresponding to a microservice. Within a Pod, the microservices deployed in different containers can belong to the same microservice system.
[0078] For example, e-commerce applications, such as shopping applications, can be divided into user services, product services, order services, and payment services based on business boundaries. Each service can be further divided into multiple independently deployed microservices. For instance, user services can be divided into microservices such as registration, login, and profile management; product services can be divided into microservices such as product publishing, search, and inventory; order services can be divided into microservices such as order placement, payment, and logistics; and payment services can be divided into microservices such as payment interface and settlement.
[0079] In step S11, a link analysis is performed on the current microservice system to determine the link relationships between related microservices; wherein, the link relationship is used to describe the type of link between related microservices, including direct dependency relationship and indirect dependency relationship.
[0080] For example, step S11 described above may include:
[0081] Step S21: Obtain the microservices in the microserver system and the links between related microservices;
[0082] Step S22: Based on the association relationship between each link and the first microservice, configure the two related links to have a direct dependency relationship; or
[0083] Step S23: Based on the association relationship between each link and the first microservice or the second microservice, configure the two links to have an indirect dependency relationship; wherein, the first microservice and the second microservice have a direct association relationship.
[0084] Specifically, the Design Structure Matrix (DSM) method can be used to identify the links between system components.
[0085] In a microservices architecture, services are the smallest units. They are small in granularity and numerous, and their communication mechanisms lead to complex dependencies. Therefore, this study focuses on the underlying microservices, summarizing and analyzing them to determine the dependencies between them. Specifically, the link between the first microservice and its directly related second microservice serves as the connection between the two related microservices.
[0086] Microservice dependencies can be categorized into the following two types:
[0087] 1) Direct Dependency. If a microservice belongs to two links, then the two links have a direct dependency relationship. For example, see [reference]. Figure 3 As shown, microservice k is a common microservice of links i and j, so links i and j have a direct dependency relationship.
[0088] 2) Indirect Dependency. If multiple microservices belong to two links, and there are dependencies between these microservices, then these two links represent an indirect dependency. For example, see [reference needed]. Figure 4 As shown, microservices k and l are common microservices of links i and j, and microservice l depends on microservice k. Therefore, links i and j have an indirect dependency relationship.
[0089] In other words, direct and indirect dependencies are used to describe the dependencies between related links; correspondingly, the dependencies between links can be determined by the dependencies between related microservices.
[0090] In step S12, based on the system architecture of the microservice system and the link relationships between related microservices, the adjacency matrix P and the system relationship matrix A corresponding to the microservice system are determined; wherein, the adjacency matrix is used to describe the dependency relationships between each microservice in the microservice system; the system relationship matrix A is used to describe the dependency relationship types between related microservices.
[0091] For example, step S12 described above may include:
[0092] Step S31: Construct an adjacency matrix P based on the dependencies between related microservices in the microservice system; and
[0093] Step S32: Construct a system relationship matrix A based on microservices and links, according to the dependencies between related microservices in the microservice system and the types of links between related microservices.
[0094] Specifically, the adjacency matrix P is primarily used to identify how services are linked and to obtain information exchanged between them. System architecture diagrams and microservice tracing tools are used to discover information about services and their links. The first step in this process is to determine how services and links depend on each other and to obtain the type and level of information exchanged between services and links.
[0095] For example, refer to Figure 5 The microservice system architecture shown consists of 6 microservices and 6 event-driven systems. The arrows indicate the dependencies between related microservices. For example, link L1 indicates that microservice M1 depends on microservice M2.
[0096] refer to Figure 6 In the adjacency matrix P shown, M1 depends on M2, so the value of P12 is 1. M3 does not depend on M2, so the value of P32 is 0.
[0097] To understand the dependencies between services in a system, it's crucial to identify the types of dependencies between microservices. In a microservices architecture, many types of dependencies can exist as services interact, communicate, and coordinate with each other.
[0098] When collecting dependency information, the system architecture diagram is updated by labeling the dependency types between two microservices. The collected dependency information is then recorded in the DSM (Distributed System Management Matrix), referred to as the System Association Matrix A. Association Matrix A identifies and retrieves the types and levels of information exchanged through service links within the system. For an identified system with n microservices and m links, A... m,n It is a rectangular matrix where m rows represent the number of links and n columns represent services. Each matrix cell a ij The value can be 1 or 0. A matrix cell value of 1 indicates that link i provides information to service j; a matrix cell value of 0 indicates that link i and service j are not associated.
[0099] For example, refer to Figure 7 The system association matrix shown illustrates a system with 6 microservices and 6 dependent links. Matrix A is a 6x6 matrix. Link L1 belongs to microservices M1 and M2 and provides information to M2. In matrix A, matrix cell a... 12The value is 1. Similarly, link L4 belongs to microservices M3 and M5, and provides information to M5, matrix unit a. 45 The value is 1.
[0100] In step S13, the explicit matrix E and implicit matrix I corresponding to the microservice system are calculated using the adjacency matrix P and the system relation matrix A. The explicit matrix E is used to represent the explicit dependencies between links in the microservice system and to describe the dependency strength of links with direct dependencies. The implicit matrix I is used to represent the implicit dependencies between links in the microservice system and to describe the dependency strength of links with indirect dependencies.
[0101] For example, step S13 may include:
[0102] Step S41: Calculate the explicit matrix E based on the system relation matrix A and its corresponding transpose matrix; and
[0103] Step S42: Calculate the implicit matrix I based on the system relation matrix A and its corresponding transpose matrix, combined with the adjacency matrix P.
[0104] Specifically, if a microservice belongs to two links, such as Figure 3 As shown, the two links are direct dependencies and are marked in matrix A. For explicit dependencies, the value of the matrix cell in the same column of matrix A is 1, i.e., a. ik =a jk =1, where link i and link j represent links shared by microservice k. A is used to calculate the total number of public microservices associated with any pair of links.
[0105] The explicit matrix E includes: .
[0106] Among them, A T It is the transpose of matrix A. For a system with n components, E n,n E is a square symmetric matrix with n rows and n columns and the same label. The matrix element values in E can be non-binary. Therefore, they can be any integer.
[0107] Off-diagonal elements in explicit matrix E e ij Indicates a link i and links j The number of public services providing information is expressed by the formula: .
[0108] For example, targeting Figure 5 The system architecture shown has 6 dependency links, and its corresponding explicit system dependency matrix E is as follows: Figure 8 As shown. For example, matrix element e 16A value of 1 indicates that the dependency links L1 and L6 provide information to the same microservice M2.
[0109] Furthermore, for implicit dependencies, if multiple microservices belong to two links, and there are dependencies between the microservices, then these two links are considered indirect dependencies. The implicit matrix I records the dependency strength between implicit dependency links.
[0110] Implicit matrix I, including: .
[0111] Each matrix cell of the implicit matrix I is defined as follows: ; where a and p are elements of the system correlation matrix A and adjacency matrix P, respectively.
[0112] For example, targeting Figure 5 In the system architecture shown, microservices M5 and M3 are linked via link L4, microservices M5 and M2 are linked via link L6, and microservices M2 and M4 are linked via link L3. M5 receives information through link L4, M2 receives information through link L6, and M4 receives information through link L3. Therefore, link L4 implicitly depends on link L6, and link L6 implicitly depends on link L3.
[0113] Using this information, we can calculate when a ik =p ik =a jl When =1, the number of links i and j that need to exchange information or depend on each other.
[0114] Consider components that are adjacent to each other and separated by one link using the following formula.
[0115] The corresponding formulas include: ; ; .
[0116] in, P I , P II and P n These represent one, two, and... respectively between services. n A matrix of links. P ] 1 , [ P ] 2 and[ P ] n They are P First, second, third n The second power derivative.
[0117] The above formula can then be modified as follows: .
[0118] Where n is the total number of services provided by the system; P actual It is DSM, which obtains the number of instances used by a service in the process of information flow between services with an interval of λ links.
[0119] Matrix P represents the relationships between services that are one link apart. In the system, relationships exist between services that are one link apart and between components that are two, three, or n links apart. When information flows from one service to another service that is n links apart, Pactual records the number of instances of a service that fall within this information flow path. To compute Pactual, services that are n links apart from other services are identified using the power derivative of P.
[0120] For a system I with m links m , is a square matrix with m rows and m columns of identical labels. Off-diagonal element I ij This indicates that link i can provide information to link j. The diagonal cells of matrix I represent the number of services associated with a link. For example, for... Figure 5 The system architecture shown, for a system with 6 dependency links, has an implicit dependency matrix I as follows: Figure 9 As shown.
[0121] In step S14, the total dependency strength of the links is calculated based on the explicit matrix E and the implicit matrix I, and the link priority is configured for each link based on the total dependency strength.
[0122] For example, step S14 may specifically include:
[0123] Step S51: Calculate the total dependency strength of the links based on the explicit matrix E and the implicit matrix I; Step S52: Configure link priorities for the corresponding two links based on the dependency strength.
[0124] Specifically, the final step of the MDD method is to calculate the total dependency strength between service links and use this total dependency strength to assign priorities to the links. The Total Link Dependency Strength Matrix (LDM) is based on explicit and implicit dependency strengths, and the formula includes: .
[0125] Wherein, LDM is the total link dependency strength matrix, a square matrix of m rows and m columns with identical labels. Each off-diagonal region represents the dependency strength of link i with link j. Dependency strength is proportional to link priority. The value of a cell represents the dependency strength between two links. (Reference) Figure 10 As shown, Figure 5 The LDM matrix of the system architecture is shown. The value of each cell represents the dependency strength between two links. The higher the value of the cell, the stronger the dependency between the links.
[0126] For example, as a data flow connecting L1 to the rest of the system, link L2 has the highest dependency strength value (first row), and is therefore the highest priority link relative to L1. Similarly, L4 is the highest priority link relative to L2, while L5 is the lowest priority link. The overall link priority of the system is then as follows: Figure 11 As shown.
[0127] For example, the method further includes: configuring a microservice priority with the same priority parameter for the microservice associated with the link based on the priority parameter of the link priority of each link.
[0128] Specifically, after determining the priority of a link, priority parameters can be configured for the corresponding microservice. For example, after determining the specific parameters for the priority of each link, the same priority value can be configured for the upstream and downstream microservices directly associated with the link. Alternatively, if a microservice has multiple directly associated links with different priorities, the link with the highest priority can be selected to configure the same microservice priority parameter for that microservice.
[0129] Specifically, by prioritizing microservice links, resources needed by high-priority services are guaranteed first, thereby improving the utilization of cluster resources. This prioritization allows for the identification of critical links, and under resource-constrained conditions, prioritizing the resource usage of critical services ensures the performance of the entire application software. Microservices that consume few resources but have strong dependencies will have their corresponding links removed during system architecture analysis. The analysis of dependencies between microservice links includes microservice-to-microservice relationships, microservice-to-link relationships, and link-to-link relationships. Using DSM analysis techniques, the dependency strength between links can be identified. Current analysis methods are limited to scenarios where the microservice architecture is not particularly complex, calculating their relative priorities based on their dependency strength. The MDD method is used to calculate the dependency strength between microservice links to identify the highest priority chain in a microservice-based application.
[0130] In step S15, in response to resource allocation indication information under resource-constrained conditions, the target microservice instance is weighted based on link priority; and the target microservice instance is deployed as a Pod based on the reconfigured weight information.
[0131] For example, step S15 may include: in response to multiple Pod deployment indication information under resource-constrained conditions, calling the PriorityClasses scheduler to create a PriorityClasses resource list, configuring priority weights for the target microservice instance based on link priority, and deploying the target microservice instance as a Pod based on the reconfigured priority weights; wherein, each container instance in the Pod belongs to the same microservice.
[0132] Specifically, Pod migration needs to consider: Under resource-constrained conditions, when multiple Pods need to be deployed, which Pod should be prioritized for deployment? When cluster resources are limited, and there is significant load, requiring scaling up of microservice instances across related microservice chains, which Pod should be prioritized for deployment? In this case, the critical path of the entire microservice application and the priorities of the microservices involved along that path can be calculated using the methods described above.
[0133] The aforementioned Pod deployment instructions can be deployment task information for services with high priority. When Kubernetes cluster resources are below the preset value, but some important services need to be deployed, the PriorityClasses resource object in Kubernetes can be used to "preempt" cluster resources, allowing the critical services to run on the cluster. PriorityClasses can be used to set weights, which are primarily based on the importance of the microservices, i.e., configured according to the link priority calculated using the method described above.
[0134] In this case, previously referenced objects can be directly referenced in the resource manifest file when creating a Pod. The creation process of the PriorityClasses resource manifest includes:
[0135] apiVersion: scheduling.k8s.io / v1# API version number
[0136] kind: PriorityClass #List of priority type resources
[0137] metadata:
[0138] name: high-priority # Type name
[0139] value: 1001 # Priority weight
[0140] globalDefault: false
[0141] Description: "This priority class should only be used for XYZ service Pods."
[0142] ---
[0143] apiVersion: scheduling.k8s.io / v1
[0144] kind: PriorityClass
[0145] metadata:
[0146] name: low-priority
[0147] value: 1000
[0148] globalDefault: false
[0149] Description: "This priority class should only be used for ABC service Pods."
[0150] Additionally, when creating a new Pod, specify the name of the priority class in the `.spec.priorityClassName` field using the newly created priority class. Referencing the PriorityClasses resource manifest can be achieved using the conventional method, which will not be elaborated upon here.
[0151] For example, step 15 above may further include:
[0152] Step S61: In response to the Pod migration instruction information under resource-constrained conditions, obtain the corresponding migration resource consumption data and node available resource data; wherein, the available resource data includes the node's current remaining resources;
[0153] Step S62: Combine migration resource consumption data and node available resource data to determine the resource allocation strategy using a container resource optimization model based on genetic algorithm;
[0154] Step S63: Based on link priority, deploy the target microservice instance to the corresponding node according to the resource configuration policy.
[0155] Specifically, considering the issue that large-scale Pod migration is not allowed, a container resource optimization model based on genetic algorithms can be used to determine the resource configuration strategy, and then Pod migration can be carried out according to the determined priority information.
[0156] Specifically, container resource allocation affects system performance and resource consumption. Resource management optimization is an NP-complete problem, and solving it using a genetic algorithm requires first modeling the containers and nodes. The container set C = {c1, c2, ..., c...} i}, where i is the total number of containers. Container c ∈ C. The resource vector required for each c to run is defined as Req(c), representing the amount of resources required for container c to run, expressed by the formula Req(c) =<cpu,mem> Where cpu represents the number of CPU cores required for the container to run, and mem represents the memory required for the container to run. This represents the number of CPU cores and the amount of memory required for container c to run.
[0157] A service S can have multiple container instances. Service S defines the number of container replicas b required and the resource vector Req(c) required for all replicas. All containers belonging to the same service S are considered homogeneous because they require the same amount of resources.
[0158] The set of compute nodes is N = {n1, n2, ..., nn} j}, where j is the total number of nodes in the cluster. Each node n∈N is assigned a set of containers C. n C n It is a subset of C. Furthermore, two resource vectors are associated with each node n.
[0159] 1) Spec(n) =<cpu, mem> These are resources based on the hardware specifications of node n, and these resources are determined at the initial stage of the cluster.
[0160] 2) Rem(n) =<cpu, mem> It represents the total resources that all containers deployed to node n can consume, as well as the remaining resources of the current node.
[0161] The scheduling problem has a single constraint: the only constraint that a container c can be deployed to node n is that the remaining resources Rem(n) of the current node are greater than or equal to the resources Req(c) required by container c.<cpu, mem> .
[0162] The genetic algorithm modeling process used in this invention is as follows:
[0163] 1) Placement Problem Encoding. Four mutation methods are used to differentiate offspring from their parents. The first method is swapping, such as exchanging nodes between two containers. The second method is alteration, such as assigning a container to a new node. The third method is assigning an unassigned container to a random node, regardless of its remaining resources. The fourth method is randomly deassigning one of the assigned containers.
[0164] 2) Initial Placement Scheme Set. In Kubernetes, Pods move frequently due to various reasons (such as node failures, changes in Pod scheduling policies, etc.). Furthermore, the iterative strategy of the genetic algorithm and the migration of Pods themselves are very costly under resource constraints. Migrating Pods with every iteration would incur significant costs and latency, impacting the algorithm's efficiency and performance. Therefore, a comprehensive Pod adjustment using a genetic algorithm cannot be applied to every cluster change. The resource allocation problem in the cluster is divided into two main steps: the first step is to add a Pod placement strategy, and the second step is to use an algorithm for global migration optimization.
[0165] When the scheduler in the cluster receives a Pod creation instruction, it first needs to select a Node before deploying the Pod. This involves Node selection strategies. The Node selection strategy mainly consists of two steps. First, Kubernetes' pre-selection algorithm eliminates all Nodes that do not meet the requirements, leaving only those suitable for deploying the current Pod. Then, an optimization algorithm scores and ranks all suitable Nodes. Since Kubernetes uses a scheduler component to perform node selection, this component considers the resource usage on each node and matches it to the Pod's resource needs to find the most suitable node. However, this component only considers CPU and memory metrics, which may lead to uneven resource exhaustion. Therefore, it's necessary to consider the compatibility of Pods and Nodes across different types of resources to ensure balanced resource consumption within the Node.
[0166] Pod is p i With Node N j Resource matching fitness i,j The formula is expressed as:
[0167] .
[0168] Here, S represents the variance of the resource, which is the degree of fluctuation of the resource. For resources such as memory or CPU, variance reflects their real-time load changes. The larger the variance, the higher the volatility of the resource, and the more difficult it is to predict and control. k represents the dimension of the resource, that is, the type of resource used. For Pod In the Demand for similar resources For nodes In the The difference between the available quantity of a Pod and a node on that resource dimension reflects the degree of matching between the Pod and the node.
[0169] CPU and memory can be understood as resources in two dimensions, so their usage needs to be considered simultaneously. The Fitness value is typically between 0 and 1 and is used to measure the quality of an algorithm or model. Therefore, when creating a new Pod, it is only necessary to iterate through all the nodes in the cluster and find the node with the highest Fitness value for deployment.
[0170] Whenever a new Pod needs to be created and deployed to a corresponding Node, the placement algorithm described above is used to select a suitable Node for deployment. Since this strategy is based on a greedy algorithm, a relatively reasonable deployment scheme can be obtained. However, in real-world business environments, the Pod request sequence cannot be predicted, and only a near-optimal solution can be achieved. Furthermore, the creation and deletion of Pods disrupts the previous cluster resource usage. Therefore, a suitable threshold needs to be set to migrate some Pods in the cluster to achieve a more balanced resource usage. This invention uses the NSGA algorithm to solve the above problem. It is important to note that in Kubernetes, the original Pod is not copied to other Nodes, as this would introduce new problems. Kubernetes deletes the old Pod and then creates a new Pod on another Node.
[0171] The initial population is based on the deployment status of the Pods in the current cluster. S initial In the initial state, the sample size of the initial population is increased using relevant operations. This is to increase the initial... S initial To perform random shuffling, a certain number of Pods must first be randomly selected from the Nodes in the cluster, and their contents changed. S initial The original Pod deployment locations were obtained S initial Then place the generated new deployment plan. S initial Add the solutions to the initial placement scheme set. Repeat the above process until the number of schemes in the placement scheme set reaches M, then output the initial placement scheme set H.
[0172] 3) Determine the evaluation function
[0173] This invention defines six objective functions to evaluate solutions, where the objective value must be minimized to achieve optimal individual criteria.
[0174] (1) Equal Task Objective Function. The equal task distribution objective function evaluates the distribution of tasks in the cluster by calculating the sum of the number T for each node, where T represents the number of tasks placed on each node. nThe number of tasks in the algorithm. The algorithm ignores the concept of task replicas, assuming that all tasks are different.
[0175] (2) Single deployment objective function. A single deployment objective function is used to ensure that each node is deployed with a different set of tasks, and each node... n Evaluation is performed by summing the number of replicas for each task type T, where R represents the number of replicas for each task type T.
[0176] (3) Node power consumption objective function. A linear power model is used to estimate the power consumption of each node in the cluster. The first factor is when the node... n When resources are fully utilized and no more tasks can be assigned to it, the node n The average power consumed. The second factor is when the node... n The node is in an idle state when no tasks are assigned. n The third is the average power consumption. The third is the average percentage of CPU and memory usage. The smaller the target value for the cluster, the more efficient it is for scheduling.
[0177] (4) Resource Utilization Balancing Objective Function. This objective function is used to evaluate the efficiency of cluster resource utilization. This is beneficial for selecting nodes with the same memory and CPU usage ratios. Therefore, the resource utilization balancing objective function eliminates the problem of fully utilizing CPU while underutilizing memory and helps to distribute the load evenly.
[0178] (5) Unassigned Task Objective Function. This objective function evaluates the number of unassigned tasks in a given solution. This objective helps to keep the number of unsigned containers small. Since unassigned tasks tend to increase the number of unassigned containers, this approach minimizes the four fitness objectives mentioned above. The solution will represent the maximum number of containers that can be assigned to cluster nodes while optimizing the remaining objectives.
[0179] (6) Rescheduling Objective Function. The rescheduling objective function reveals the differences between the two clusters in terms of container allocation. The motivation behind this objective function is that moving containers involves undesirable overhead, and it is undesirable to assemble new nodes at the cost of moving most containers. When a new container is added, if it is not possible to allocate the new container node, a rescheduling is performed, but if the remaining CPU and memory allow for the allocation of the new container, the system should reset the given allocation so that the new configuration will be effective. To evaluate the different permutations, the permutation with fewer moves is chosen, as doing less work to achieve a similar plan is the optimal choice. The implementation of this objective is slightly different because the chromosome (the existing allocation for which new containers cannot be allocated) is passed before rescheduling and compared with the calculated chromosome.
[0180] 4) Genetic Algorithm Iterative Strategy
[0181] (1) Selection Strategy. After determining the evaluation function of the genetic algorithm, a selection strategy needs to be formulated. The selection strategy includes how to choose the mutation method and how many individuals to select. The purpose is to select relatively excellent individuals from the initial population and pass them on to the next generation through genetic mutation and other operations. This paper adopts the tournament selection strategy. The basic idea of tournament selection is to randomly select several individuals from the population, and then select the best individual from them as the parent for crossover and mutation operations. The tournament selection strategy randomly selects k individuals from the current population and forms them into a tournament.
[0182] The tournament selection strategy is a sampling strategy with replacement. Its basic idea is to randomly select k individuals from the current population and form a tournament with them. This means that each of these k individuals can be selected multiple times or may be ignored. Assuming the population size is M and the tournament size is k, using a sampling strategy with replacement, in each round of tournament selection, k individuals need to be randomly selected from the current population as tournament participants. Because it is sampling with replacement, the probability of each individual being selected is 1 - (1 / M). k .
[0183] (2) Crossover Strategy. After determining the individuals to be included in the next generation, the crossover strategy is an important step in the genetic algorithm. The crossover strategy can be used to generate new individuals and, combined with mutation strategies, further optimize the population. Specifically, the crossover strategy can be divided into the following steps:
[0184] 1. Randomly select k individuals from the current population and form a tournament among them; 2. Compare the fitness values of each individual in the tournament and select the individual with the highest fitness as the first parent individual; 3. Repeat steps 1 and 2 to select the individual with the second highest fitness as the second parent individual; 4. Perform a crossover operation on the first and second parent individuals to generate new offspring individuals and add them to the next generation population; 5. Repeat the above operations until the offspring population size reaches M.
[0185] Since binary tournament selection only requires randomly selecting two individuals from the current population, it is computationally efficient and suitable for problems with large population sizes. Furthermore, multiple binary tournament selections ensure selection diversity and exploration capabilities, improving the optimization performance of the genetic algorithm.
[0186] (3) Mutation operation. When migrating Pods in the cluster, a child scheme is first randomly selected, and a Pod is randomly selected from the scheme and then migrated to another Node. If the selected Node cannot meet the resource specifications of the Pod, a new Node is selected until a Node that meets the requirements is found.
[0187] (4) Termination Condition. In genetic algorithms, the termination condition is the basis for determining whether the algorithm should stop. A correct termination condition can effectively control the search time and convergence accuracy of the algorithm, thereby improving the efficiency and optimization quality. This paper uses the standard deviation of the population evaluation function and the maximum number of iterations to determine whether to terminate the iteration. The formula includes:
[0188] .
[0189] Where M represents the number of placement schemes. f (i) represents the fitness of the current placement scheme. f avg Let σ be the mean fitness of the population placement scheme, and σ be the termination threshold. The iteration terminates when σ is greater than the calculated fitness standard deviation.
[0190] After the genetic algorithm iteration terminates, the placement scheme for the Pods can be determined. At this point, based on the determined link priority, the corresponding microservices are deployed according to the determined placement scheme in descending order of priority; and the containers corresponding to the microservices are assigned to the corresponding nodes.
[0191] Additionally, after determining the node set, container set, and the parameters required for executing the genetic algorithm, the initial container allocation locations are generated using the Kubernetes scheduling policies PodFitResources and LeastRequestPriority. The parameters passed to NSGA-III use the exact same node and container sets as Kubernetes. A non-dominated sort is performed on the final population, and then the optimal frontier is collected. When all containers have been allocated to nodes and the entire cluster resources are about to reach saturation, multiple new microservice instances are added—microservice instances are allocated resources based on the priority obtained from the DSM. Since the current cluster no longer has suitable nodes for the new containers, rescheduling is necessary.
[0192] First, the rescheduling algorithm is run, and the optimal frontier obtained from the results of the unallocated new container—NSGA-III—is passed as a parameter. Second, the scheduling algorithm is run on an empty node, and the allocation results are returned, yielding an optimal solution that includes the allocation results for all containers. Finally, the allocation results from the two calculations are evaluated by the sixth rescheduling objective function.
[0193] refer to Figure 13 The diagram illustrates the dynamic training process for five objective functions. The red field represents the population objective value, and the blue line represents its average value. The continuously decreasing lower bound indicates that the fitness function is constantly eliminating individuals, ultimately leaving only the optimal result after several iterations. The lower bound decreases for most tasks, meaning that some solutions improve the fitness value for these tasks. This is a primary criterion for evaluating the success of the algorithm. An increasing upper bound indicates that the search space is being explored. The blue average line represents the position where the population density tends towards the upper or lower bound.
[0194] For example, this invention designs a container resource optimization model based on genetic algorithms. Considering the limited resources of cloud-native clusters, and combining the characteristics of cloud-native environments, the genetic algorithm is used as the primary method for solving NP problems. The genetic algorithm is optimized from aspects such as genetic coding design, initialization population scheme, and objective function design. This optimizes the speed and quality of the solution of traditional genetic algorithms, and ensures the rationality of container resource allocation and system stability under resource-constrained conditions.
[0195] For example, the method further includes:
[0196] Step S71: Obtain the current state of the microservice; wherein, the microservice state includes: stateless service and stateful service;
[0197] Step S72: Based on the user's custom parameters for the target microservice, call the StatefulSet workload controller to execute the corresponding custom parameters for the stateful service microservice instance.
[0198] Specifically, microservice deployments are divided into stateless services and stateful services. Stateless services do not store persistent data locally. Multiple service instances will provide completely identical responses to the same user request. These multiple service instances have no dependencies on each other. For example, in a web application, dynamically starting and stopping a stateless service Pod in the Kubernetes controller will not affect other Pods.
[0199] Stateful services require local data persistence, typically in distributed database applications where distributed node instances have dependent topological relationships. If Kubernetes stops any instance Pod in the distributed cluster, it could lead to data loss or cluster crashes.
[0200] Migrating stateful services relies on StatefulSet resource objects provided by Kubernetes. Similar to Deployments, StatefulSets manage their Pods based on a Pod template. The biggest difference from Deployments is that StatefulSets always assign a set of immutable names to their Pods. These Pods are created from the same template but cannot be interchanged: each Pod corresponds to a unique persistent storage identifier. Like all other controllers, StatefulSets operate using the same pattern: users define their expected results in the StatefulSet, and the StatefulSet controller executes the necessary operations to achieve that result.
[0201] For example, the microservice application uses SockShop provided by WeaveCloud. SockShop provides an e-commerce website that simulates the sale of socks. A list of microservice instance resources is provided for building SockShop. For detailed configuration of microservices, please refer to the official website.
[0202] Deploy SockShop into the cluster and use Kuboard to visualize cluster resources. For easier management, use different namespaces to divide the cluster resources. The monitoring namespace is mainly used to monitor the resources (CPU, memory, disk) of the entire cluster.
[0203] The method provided in this invention employs a Design Structure Matrix (DSM) and a multi-dimensional dependency (MDD) analysis model to calculate the link priority of the entire microservice application, thereby determining the priority of all microservices within the application. All microservices are then sorted according to the priority list, ensuring that high-priority services are guaranteed resources under resource-constrained conditions, thus improving the stability of the entire system. A scheduling strategy based on a genetic algorithm is designed and optimized, encompassing the encoding of the genetic algorithm's placement problem, generation of initial placement schemes, determination of the evaluation function, and the iterative strategy of the genetic algorithm. This reduces resource consumption costs and solves the container resource scheduling problem under resource-constrained environments.
[0204] This method takes into account the limited resources of cloud-native clusters and uses genetic algorithms as the primary method for solving NP problems. It uses genetic algorithms for optimization, continuously generating new solutions and gradually finding the optimal solution through selection, crossover, and mutation operations.
[0205] It should be noted that the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Furthermore, it is readily understood that these processes may, for example, be executed synchronously or asynchronously in multiple modules.
[0206] It should be noted that although several modules or units of the device for performing actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.
[0207] Figure 14 A schematic diagram of an electronic device suitable for implementing embodiments of the present invention is shown.
[0208] It should be noted that, Figure 14 The electronic device 1000 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.
[0209] like Figure 14 As shown, the electronic device 1000 includes a Central Processing Unit (CPU) 1001, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1002 or programs loaded from storage section 1008 into Random Access Memory (RAM) 1003. The RAM 1003 also stores various programs and data required for system operation. The CPU 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An Input / Output (I / O) interface 1005 is also connected to the bus 1004. Furthermore, the electronic device 1000 also includes an FPGA device and a System-on-a-Chip (SoC) device.
[0210] The following components are connected to I / O interface 1005: an input section 1006 including a keyboard, mouse, etc.; an output section 1007 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to I / O interface 1005 as needed. Removable media 1011, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1010 as needed so that computer programs read from them can be installed into storage section 1008 as needed.
[0211] In particular, according to embodiments of the present invention, the processes described below with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a storage medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1009, and / or installed from removable medium 1011. When the computer program is executed by central processing unit (CPU) 1001, it performs various functions defined in the system of this application.
[0212] Specifically, the aforementioned electronic devices can be airborne intelligent electronic devices, such as airborne video processing equipment.
[0213] It should be noted that the storage medium shown in the embodiments of the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, wherein computer-readable program code is carried. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any storage medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the storage medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.
[0214] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0215] The units described in the embodiments of the present invention can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.
[0216] It should be noted that, as another aspect, this application also provides a storage medium, which may be included in an electronic device or may exist independently without being assembled into the electronic device. The aforementioned storage medium carries one or more programs, which, when executed by an electronic device, cause the electronic device to perform the methods described in the following embodiments. For example, the electronic device may perform... Figure 1 The steps of the method shown.
[0217] In one embodiment, this application provides a computer program product including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.
[0218] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.
[0219] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the claims.
[0220] It should be understood that the present invention is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.
Claims
1. A method for optimizing container resources based on a microservice architecture in a resource-constrained environment, characterized in that, The method includes: Perform link analysis on the current microservice system to determine the relationships between related microservices. The link relationship describes the type of dependency between microservices, including direct dependency and indirect dependency. If a microservice belongs to two links, then the two links have a direct dependency relationship. If multiple microservices belong to two links and there are dependencies between the microservices, then the two links have an indirect dependency relationship. Based on the system architecture of the microservice system and the link relationships between related microservices, the adjacency matrix P and system relation matrix A corresponding to the microservice system are determined. The adjacency matrix describes the dependencies between microservices within the microservice system; the system relation matrix A describes the types of dependencies between related microservices. The relation matrix A corresponds to an identified system with n microservices and m links, where m rows represent the number of links and n columns represent services. Each matrix unit a... ij The value is 1 or 0; a matrix cell value of 1 indicates that link i provides information to service j; a matrix cell value of 0 indicates that link i and service j are not associated. The explicit matrix E and implicit matrix I corresponding to the microservice system are calculated using the adjacency matrix P and the system relation matrix A. This includes: calculating the explicit matrix E based on the system relation matrix A and its corresponding transpose matrix; and calculating the implicit matrix I based on the system relation matrix A and its corresponding transpose matrix, combined with the adjacency matrix P. The explicit matrix E represents the explicit dependencies between links in the microservice system and describes the dependency strength of links with direct dependencies. The implicit matrix I represents the implicit dependencies between links in the microservice system and describes the dependency strength of links with indirect dependencies. The total dependency strength of the links is calculated based on the explicit matrix E and the implicit matrix I, and the link priority is configured for the corresponding two links based on the total dependency strength; where the total dependency strength is proportional to the link priority. Based on the priority parameters of each link, configure the microservice priority with the same priority parameter for the microservice associated with that link. This includes configuring the same priority information for upstream and downstream microservices that are directly associated with the link; or, if a microservice has multiple directly associated links and the links have different priorities, the link with the highest priority can be selected to configure the microservice priority with the same parameter for that microservice. In response to resource allocation instructions under resource-constrained conditions, the target microservice instance is weighted based on link priority; and Pods are deployed to the target microservice instance based on the reconfigured weight information, including: In response to multiple Pod deployment instructions under resource-constrained conditions, the PriorityClasses scheduler is invoked to create a PriorityClasses resource list. Priority weights are configured for the target microservice instance based on link priority, and Pods are deployed to the target microservice instance based on the reconfigured priority weights. Each container instance within a Pod belongs to the same microservice. Pod migration needs to consider: under resource-constrained conditions, when multiple Pods need to be deployed, which Pod should be deployed first? Multiple Pod deployment instructions can be deployment task information for services with higher importance levels. Alternatively, considering the issue that large-scale Pod migration is not permitted, in response to Pod migration instructions under resource-constrained conditions, the corresponding migration resource consumption data and node available resource data are obtained; where available resource data includes the current remaining resources of the node; combining the migration resource consumption data and node available resource data, a container resource optimization model based on a genetic algorithm is used to determine the resource configuration strategy; based on link priority, the target microservice instance is deployed to the corresponding node according to the resource configuration strategy; wherein, the resource configuration strategy determined by combining the migration resource consumption data and node available resource data using a container resource optimization model based on a genetic algorithm includes: defining the NP-complete problem corresponding to the resource configuration strategy and modeling the containers and nodes; encoding the placement problem of containers and nodes, configuring an initial placement location scheme set; determining the evaluation function and determining the iteration strategy of the genetic algorithm; performing iterative calculations on the initial placement location scheme set based on the iteration strategy until the iteration terminates, determining the node placement scheme, which is used to deploy the corresponding microservices according to the determined placement scheme based on the determined link priority.
2. The method according to claim 1, characterized in that, Perform link analysis on the current microservice system to determine the relationships between related microservices, including: Obtain the microservices in the microserver system, as well as the links between related microservices; Based on the association between each link and the first microservice, configure the two related links to have a direct dependency relationship; or Based on the association between each link and the first or second microservice, the two links are configured to have an indirect dependency relationship; among them, the first microservice and the second microservice have a direct association relationship.
3. The method according to claim 1, characterized in that, Based on the system architecture of the microservice system and the links between related microservices, determine the adjacency matrix P and system relationship matrix A corresponding to the microservice system, including: Based on the dependencies between related microservices in a microservice system, construct an adjacency matrix P based on the microservices; and Based on the dependencies between related microservices in the microservice system and the types of links between related microservices, construct a system relationship matrix A based on microservices and links.
4. The method according to claim 1, characterized in that, Using the adjacency matrix P and the system relation matrix A, calculate the explicit matrix E and implicit matrix I corresponding to the microservice system, including: Calculate the explicit matrix E based on the system relation matrix A and its corresponding transpose matrix, including: Among them, the off-diagonal elements in the explicit matrix E e ij Indicates a link i and links j The number of public services that provide information; and Based on the system relation matrix A and its corresponding transpose matrix, and in conjunction with the adjacency matrix P, the implicit matrix I is calculated, including: Each matrix cell of the implicit matrix I is defined as follows: , where a and p are elements of the system correlation matrix A and adjacency matrix P, respectively.
5. The method according to claim 1, characterized in that, The total dependency strength of the links is calculated based on the explicit matrix E and the implicit matrix I, and link priorities are configured for each link based on the total dependency strength, including: The total dependency strength of the links is calculated based on the explicit matrix E and the implicit matrix I, including: Wherein, LDM is the total link dependency strength matrix, and the value of a cell in the matrix represents the dependency strength between two links; Configure link priority for the two corresponding links based on dependency strength.
6. The method according to claim 1, characterized in that, The method further includes: Get the current state of the microservice; where the microservice state includes: stateless service and stateful service; Based on the user's custom parameters for the target microservice, the StatefulSet workload controller is invoked to execute the corresponding custom parameters on the microservice instance that is a stateful service.
7. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the container resource optimization method based on microservice architecture in a resource-constrained environment as described in any one of claims 1 to 6.