Container deployment method, device, electronic equipment and storage medium for power load control terminals

Abstract

This disclosure provides one or more embodiments of a container deployment method, apparatus, electronic device, and storage medium for a power load control terminal. The method includes: acquiring multiple microservices corresponding to at least one power service of the power load control terminal; constructing a container image file corresponding to the microservice based on the service level and security level of the microservice; in response to receiving a deployment request for any of the microservices, determining whether the microservice is allowed to be deployed on the power load control terminal based on the requirements of the microservice and the resources of the power load control terminal; and in response to determining that the microservice is allowed to be deployed on the power load control terminal, deploying a container corresponding to the microservice on the power load control terminal based on the container image file.

Description

Technical Field

[0001] This disclosure relates to the technical field of one or more embodiments, and more particularly to a container deployment method, apparatus, electronic device, and storage medium for a power load control terminal. Background Technology

[0002] It should be noted that the above description of the technical background is only for the purpose of providing a clear and complete explanation of the technical solutions of the present invention and facilitating understanding by those skilled in the art. It should not be assumed that the above technical solutions are known to those skilled in the art simply because they have been described in the background section of this invention.

[0003] With the development of intelligent power systems, the functions of power load control terminals are becoming increasingly complex. Traditional deployment methods based on physical machines or virtual machines have problems such as low resource utilization, poor scalability, and difficulty in upgrading and maintenance.

[0004] Microservice architecture decouples solutions by breaking down functionality into discrete services, thereby reducing system coupling and providing more flexible service support. Containerization is a lightweight virtualization technology that allows developers to package applications and their dependencies into independent, portable containers. With the rise of microservice architecture, containerization technology has played an irreplaceable role. This application combines microservice architecture and containerization to decompose power business processes into discrete services and package these services into containers for deployment on power load control terminals.

[0005] However, the general containerization solutions of related technologies do not take into account the high reliability and real-time characteristics of power business, resulting in significant deficiencies in dynamic resource scheduling and energy efficiency management. Summary of the Invention

[0006] In view of the above, the purpose of one or more embodiments of this disclosure is to provide a container deployment method, apparatus, electronic device and storage medium for a power load control terminal to solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the first aspect of this disclosure provides a container deployment method for a power load control terminal, comprising: Obtain at least one power service corresponding to multiple microservices from the power load control terminal; Based on the business level and security level of the microservice, construct the container image file corresponding to the microservice; In response to receiving a deployment request for any of the microservices, the system determines whether the microservice is allowed to be deployed on the power load control terminal based on the requirements of the microservice and the resources of the power load control terminal. In response to determining that the microservice is permitted to be deployed on the power load control terminal, the container corresponding to the microservice is deployed on the power load control terminal based on the container image file.

[0008] Optionally, the requirements of the microservice include a first computing power resource, a first memory resource, and a first storage resource required to deploy the microservice, and the resources of the power load control terminal include a second computing power resource, a second memory resource, and a second storage resource available to the power load control terminal. Based on the requirements of the microservice and the resource availability of the power load control terminal, the determination of whether to allow the deployment of the microservice includes: The first health status of the power load control terminal is obtained based on the ratio of the second computing power resource to the total computing power resource of the power load control terminal, the ratio of the second memory resource and the fragmentation value of the power load control terminal multiplied by the total memory resource of the power load control terminal, and the load of the power load control terminal. In response to the first health level being greater than the first threshold and the first computing power resource being less than the second computing power resource, the first memory resource being less than the second memory resource, and the first storage resource being less than the second storage resource, the microservice is allowed to be deployed on the power load control terminal.

[0009] Optionally, it also includes: In response to the first health level not exceeding the first threshold, the priority of the microservice is calculated based on the business level and the security level of the microservice; the priority is divided into high priority, medium priority and low priority according to the level. In response to the first health level being less than the second threshold and the microservice being of low priority, the microservice is not allowed to be deployed on the power load control terminal; In response to the first health level being between the second threshold and the first threshold and the microservice being of medium priority, wait for the power load control terminal to release available resources; In response to the microservice being of high priority, the microservice is permitted to be deployed on the power load control terminal.

[0010] Optionally, in response to the microservice being of high priority, deploying the container corresponding to the microservice on the power load control terminal based on the container image file includes: Based on the service level of the containers already deployed on the power load control terminal, at least one candidate container is selected; The preemption cost of the candidate container is obtained based on its priority, resource consumption, and service terminal cost. Iteratively eliminate candidate containers with the lowest preemption cost until the allowability value of the microservice is greater than the first threshold. The container corresponding to the microservice is deployed on the power load control terminal based on the container image file.

[0011] Optionally, the service level includes a first service level L1, a second service level L2, and a third service level L3, and the security level includes a first security level S1, a second security level S2, and a third security level S3. Based on the business level and security level of the microservice, construct the container image file corresponding to the microservice, including: A minimized vulnerability image is used for the microservices of L1S1 or L1S2, a lightweight base image is used for the microservices of L1S3, L2S1 or L2S2, and a general base image is used for the microservices of L1S3, L2S1 or L2S2. An enhanced security policy is adopted for the microservices of L1S1, L1S2, L2S1 or L3S1, a standard security policy is adopted for the microservices of L1S3, L2S2 or L3S2, and a basic security policy is adopted for the microservices of L2S3 or L3S3. The microservices of L1 adopt a high resource strategy and a high real-time guarantee strategy, the microservices of L2 adopt a medium resource strategy and a medium real-time guarantee strategy, and the microservices of L3 adopt a low resource strategy and a low real-time guarantee strategy.

[0012] Optionally, it also includes: In response to the load of the power load control terminal exceeding a third threshold, the computing resources of the L1 container deployed by the power load control terminal are increased, the computing resources of the L2 container deployed by the power load control terminal are reduced, and the L3 container deployed by the power load control terminal is suspended. In response to the power load control terminal having a threat level higher than a fourth threshold, computing resources are added to the container deployed by the power load control terminal in S2 based on the threat level, and access permissions to the container deployed by the power load control terminal are tightened. In response to the power load control terminal returning to normal, the L3 container is restarted in batches, and the computing resources of the L1 and L2 containers are gradually restored.

[0013] Optionally, it also includes: The second health of the container is calculated based on its process status, available resources, message output frequency, and business logic deployed on the power load control terminal; the business logic indicates whether it can respond normally to lightweight simulation requests. In response to the second health level falling below the fifth threshold, the service level of the container is determined; In response to the container described in L1, either restart the container immediately or deploy the container to an adjacent power load control terminal; In response to the container described in L2, the container is restarted within a preset time window based on the load of the power load control terminal; In response to the container described in L3, the container is restarted according to the load of the power load control terminal.

[0014] A second aspect of this disclosure provides a container deployment apparatus for a power load control terminal, comprising: The acquisition module is configured to acquire multiple microservices corresponding to at least one power service of the power load control terminal; The build module is configured to build the container image file corresponding to the microservice based on the business level and security level of the microservice; The judgment module is configured to, in response to receiving a deployment request for any of the microservices, determine whether the microservice is allowed to be deployed on the power load control terminal based on the requirements of the microservice and the resources of the power load control terminal; The deployment module is configured to deploy the container corresponding to the microservice on the power load control terminal based on the container image file in response to determining that the microservice is allowed to be deployed on the power load control terminal.

[0015] A third aspect of this disclosure provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as described in the first aspect.

[0016] In a fourth aspect, this disclosure provides a non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the method as described in the first aspect.

[0017] As described above, this disclosure provides a container deployment method, apparatus, electronic device, and storage medium for a power load control terminal. Based on the business and security levels of microservices, it differentiates the container image files corresponding to the microservices, thereby achieving differentiated management of power services and meeting the actual needs of power services. Furthermore, by comparing the containerization requirements of microservices with the resources of the power load control terminal, it regulates container deployment, achieving reasonable scheduling of available resources of the power load control terminal. Through the technical solution of this disclosure, the available resources of the power load control terminal can be reasonably scheduled, improving the management effectiveness of the power load control terminal. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in one or more embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the accompanying drawings described below are only one or more embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating a container deployment method for a power load control terminal according to one or more embodiments of this disclosure; Figure 2 This is a schematic diagram of the structure of a container deployment device for a power load control terminal according to one or more embodiments of the present disclosure; Figure 3 This is a schematic diagram of the hardware structure of an electronic device according to one or more embodiments of this disclosure. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0021] It should be noted that, unless otherwise defined, the technical or scientific terms used in one or more embodiments of this disclosure should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms "first," "second," and similar words used in one or more embodiments of this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0022] In the embodiments of this disclosure, the power business is based on the power system’s production, transmission, distribution, dispatch, marketing, operation and maintenance, and is a variety of specific businesses carried out to meet the electricity demand of power users or the operation and management needs of power companies.

[0023] Microservices are an architectural design pattern that breaks down a single power service into multiple small, autonomous, loosely coupled service units. Each service unit focuses on completing a single business function, interacts with other services through lightweight communication mechanisms, and can be independently developed, deployed, and scaled. In this embodiment of the disclosure, a power service can be broken down into multiple microservices.

[0024] Containerization is a lightweight virtualization technology that, through operating system-level isolation mechanisms, packages an application and its dependent runtime environment into a standardized, portable unit that can run consistently in any environment that supports a container engine. In this embodiment, each microservice is deployed in an independent container, achieving runtime environment isolation and resource limitation for the microservice.

[0025] A service is a callable functional module that can provide specific business capabilities or functional support to other modules or power load control terminals. In this embodiment, there is a one-to-one correspondence between a service and a container. The container is the runtime carrier of the service, and a running instance of a container implements the function of a service.

[0026] Based on some implementations of this disclosure, a container deployment scheme for a power load control terminal is provided. In this scheme, container image files corresponding to microservices are constructed differently based on their business and security levels, thereby achieving differentiated management of power services and meeting the actual needs of power services. Furthermore, by comparing the containerization requirements of microservices with the resources of the power load control terminal, the deployment of containers is adjusted to achieve reasonable scheduling of the available resources of the power load control terminal. Through the technical solution of this disclosure, the available resources of the power load control terminal can be reasonably scheduled, improving the management effectiveness of the power load control terminal.

[0027] The container deployment method for power load control terminals disclosed herein, comprising one or more embodiments, is applied to a power system, which may include a power master station and multiple power load control terminals.

[0028] refer to Figure 1 The present disclosure discloses a container deployment method for a power load control terminal according to one or more embodiments, comprising the following steps: Step S101: Obtain multiple microservices corresponding to at least one power service of the power load control terminal; Step S102: Based on the business level and security level of the microservice, construct the container image file corresponding to the microservice; Step S103: In response to receiving any deployment request of the microservice, determine whether the microservice is allowed to be deployed on the power load control terminal based on the requirements of the microservice and the resources of the power load control terminal; Step S104: In response to determining that the microservice is allowed to be deployed on the power load control terminal, deploy the container corresponding to the microservice on the power load control terminal based on the container image file.

[0029] In this embodiment of the disclosure, the power service is decomposed into multiple independent microservices according to the boundaries of the business functions and based on the principle of "high cohesion and low coupling".

[0030] In the embodiments of this disclosure, the service level of power services is classified according to the real-time requirements and criticality of power services, and the security level of power services is classified according to the security sensitivity of the data involved in the power services or the operations performed on the involved services.

[0031] Because each power service corresponds to multiple microservices, and there is a correspondence between power services and microservices, the business level and security level of a power service are also the business level and security level of its corresponding microservice.

[0032] In some embodiments, the service level (L-Level) may include a first service level (L1), a second service level (L2), and a third service level (L3). Interruption or delay of power services (or microservices) at the first service level will directly lead to grid control failure or trigger a safety accident; power services (or microservices) at the second service level handle more critical tasks or involve more important data, have lower real-time requirements, and can tolerate short-term interruptions; interruptions of power services (or microservices) at the third service level have a smaller impact on the core functions of the power system. For example, an L1 power service (or microservice) could be load control execution, which must respond to dispatch instructions in real time and has extremely low interruption tolerance; an L2 power service (or microservice) could be secure encryption, which has lower real-time requirements but cannot tolerate long-term interruptions to ensure data security; an L3 power service (or microservice) could be log uploading or (batch) processing of non-critical data, which has lower real-time requirements and can tolerate long-term interruptions.

[0033] In some embodiments, the security level (S-Level) may include a first security level (S1), a second security level (S2), and a third security level (S3). Specifically, the power service (or microservice) at the first security level may directly impact the safety of power grid equipment or personal safety upon failure; the data processed by the power service (or microservice) at the second security level involves user privacy or core data related to power system operation, and its leakage would pose a significant risk; the data processed by the power service (or microservice) at the third security level is public or non-sensitive data. For example, the power service (or microservice) at S1 may be load control execution, the power service (or microservice) at S2 may be secure encryption or partial edge computing analysis, and the power service (or microservice) at S3 may be logs from a power load control terminal.

[0034] A container image file represents the offline storage form of a container image. It contains all the content needed to run a container, including application code, dependency libraries, runtime environment, and configuration files. It is characterized by being lightweight, efficient, and portable.

[0035] In this embodiment of the disclosure, container image files corresponding to microservices are constructed based on the service level and security level of the service and a preset differentiated containerization strategy. This differentiated processing provides a quantitative basis for subsequent resource scheduling.

[0036] As mentioned above, the business level is related to the importance of the power business (or microservice) and requires real-time performance; the security level is related to the data privacy and importance of the power business (or microservice) and requires data security. Therefore, in the container image file building strategy, the business level determines the strategy's resource allocation and real-time requirements, while the security level determines the security hardening requirements.

[0037] It is important to note that in some embodiments, service level requirements are given priority, or the requirements of the service level take precedence over the requirements of the security level. The characteristics of a power system include the real-time nature, reliability, continuity, and physical interconnectivity of services. Specifically, the service requirements for real-time performance, reliability, and continuity are strongly correlated with the service level, while the security level provides further assurance regarding continuity and reliability.

[0038] In some embodiments, as shown in the table below, microservices of different business levels and security levels have different requirements for the base image strategy, security hardening strategy, and (resource and) real-time strategy in the container image file building strategy based on different business characteristics.

[0039]

[0040] Specifically, L1S1 containers, based on high real-time performance and high reliability, aim to ensure high priority for containers through specific container image building strategies, achieving the highest deterministic performance and security. L1's characteristics require containers to have high stability and low latency. Minimizing vulnerable images can reduce the attack surface and potential interference at the source, avoiding the impact of irrelevant processes and security vulnerabilities on the container. Furthermore, L1's characteristics also require containers to adopt high-resource strategies and high-real-time guarantee strategies to ensure millisecond / microsecond-level response capabilities, preventing lower-priority tasks from preempting container resources and maintaining container competitiveness. S1's characteristics require containers to adopt a "zero-trust" principle, ensuring that even if a container is breached by an attack, the destructive power of that attack is strictly limited.

[0041] L1S2 containers are designed for high real-time performance, aiming to ensure both real-time performance and data security through specific container image building strategies. Similar to L1S1, L1 requires containers to use minimally vulnerable images, high-resource strategies, and high-real-time guarantee strategies to ensure high real-time performance and high priority. S2, however, prioritizes data leakage prevention, ensuring container security as much as possible while maintaining real-time performance. Since S2 is slightly lower than S1, and the embodiments of this disclosure emphasize the importance of business-level security, when business-level and security-level requirements conflict, the security hardening strength can be slightly less than L1S1; for example, strong access control may not be enabled.

[0042] L1S3 containers are designed for high real-time performance, aiming to guarantee real-time performance through specific container image build strategies, while allowing for more relaxed security policies. Although L1 has high performance requirements, S3 has lower security requirements and can use lightweight base images, simplifying build and dependency management while generally meeting L1's real-time requirements. Furthermore, similar to L1S1, it employs high-priority resource strategies and high-real-time guarantee strategies to ensure both high real-time performance and high priority.

[0043] L2S1 containers, based on their high security features, aim to balance container reliability and security through specific container image building strategies. Their resource acquisition priority can be lower than that of L1S1 containers. Considering that L2 containers have lower requirements for startup speed and resource consumption than L1 containers, a lightweight base image that strikes a balance between security and size can be chosen. Simultaneously, considering the lower requirements for real-time performance and the high requirements for reliability, a medium-priority resource strategy and a medium-real-time guarantee strategy can be adopted. This provides a high level of resource guarantee while ensuring container reliability, ensuring that prolonged interruptions due to insufficient resources are not avoided.

[0044] L2S2 containers have slightly lower requirements for real-time performance and security, and are designed to balance configurations through specific container image build strategies. This balances the performance, resource, and security requirements of L2 and S2. Lightweight base images, standard security policies, medium-priority resource policies, and medium-real-time guarantee policies can be employed.

[0045] L2S3 containers have high but not stringent reliability requirements and lower security requirements. They aim to ensure business continuity through specific container image building strategies, while simplifying security policies while maintaining continuity. To improve development and operational efficiency, a general base image strategy, a basic security scanning strategy, a medium-priority resource strategy, and a medium-real-time guarantee strategy can be adopted.

[0046] While L3S1 containers do not have high requirements for reliability and other operational performance, their operation may indirectly affect the power system, thus requiring high security performance. To simplify strategies while ensuring security performance, a general base image strategy, an enhanced security strategy, a low-priority resource strategy, and a low-real-time guarantee strategy can be adopted.

[0047] L3S2 containers have lower requirements for reliability and other business performance, and lower security requirements than S1 level containers, but they may still access sensitive data, requiring protection against data leakage. Therefore, a general base image strategy, standard security hardening, low-priority resource strategy, and low real-time guarantee strategy can be adopted.

[0048] L3S3 containers have minimal impact on the overall performance of the power system, aiming to maximize resource utilization efficiency through specific container image files and avoid any interference with other critical power services. Therefore, it can maximize resource conservation by employing a general base image strategy, a basic security scanning strategy, a low-priority resource strategy, and a low-real-time guarantee strategy.

[0049] In short, in some embodiments, a minimized vulnerability image is used for the microservices of L1S1 or L1S2, a lightweight base image is used for the microservices of L1S3, L2S1 or L2S2, and a general base image is used for the microservices of L1S3, L2S1 or L2S2. An enhanced security policy is adopted for the microservices of L1S1, L1S2, L2S1 or L3S1, a standard security policy is adopted for the microservices of L1S3, L2S2 or L3S2, and a basic security policy is adopted for the microservices of L2S3 or L3S3. The microservices of L1 adopt a high resource strategy and a high real-time guarantee strategy, the microservices of L2 adopt a medium resource strategy and a medium real-time guarantee strategy, and the microservices of L3 adopt a low resource strategy and a low real-time guarantee strategy.

[0050] In some embodiments, under the special scenario of power load control terminal, the above container image file building strategy can also be adjusted.

[0051] In some embodiments, during peak load periods of the power load control terminal (when the load of the power load control terminal exceeds a third threshold), computing resources are increased for the L1 containers already deployed on the power load control terminal based on the load, computing resources are reduced for the L2 containers already deployed on the power load control terminal, and the L3 containers already deployed on the power load control terminal are suspended.

[0052] For example, during peak summer electricity consumption or when large industrial equipment suddenly starts up, the load in a specific area of ​​the power grid rises sharply, approaching or exceeding a safety threshold, posing a risk of line overload, equipment damage, or even widespread power outages. In this situation, the load state expression... ( This represents the actual load at time t. Indicates the base load. If the load of the power load control terminal is determined to be greater than a preset threshold (e.g., 0.85) based on the maximum allowable load, then the CPU share guarantee value is immediately increased for the container (level L1S1) serving the load control. The expression can be: ( (This represents a proportionality coefficient). The higher the load status value, the higher the guaranteed increase in CPU share, ensuring a rapid response to peak shaving commands from the dispatch center. Reduce the CPU share limit for edge real-time line loss analysis services (Level L2S2) (e.g., by 40%) and lower their computation frequency. For services such as operation log upload (Level L3S3), issue a "pause" command directly to immediately release the CPU and memory resources they occupy. By rapidly allocating the limited CPU resources of the power load control terminal to the most critical mission of "load control" (higher-level container), thorough preparations are made to handle upcoming dispatch commands, ensuring the physical security of the power grid.

[0053] In some embodiments, when the power load control terminal is subjected to a network attack (the threat level is higher than the fourth threshold), the computing resources of the S2 containers deployed on the power load control terminal are increased according to the threat level, and the access permissions of the containers deployed on the power load control terminal are tightened.

[0054] For example, when a power load control terminal detects abnormal network traffic such as frequent port scans, malicious connection attempts, or denial-of-service (DDoS) attacks, the data communication between the power load control terminal and the power system faces the risk of leakage or interruption. In this case, the threat level of the power load control terminal, based on data assessments such as attack frequency and alarm severity, is determined to be higher than the fourth threshold. At this point, more computing resources are allocated to the security encryption service (Level 2S2) to strengthen encryption operations and increase the frequency of security log audits, building a robust digital defense. For all non-core containers (such as L3-level log uploads and L2-level edge analytics), the policy engine automatically issues network policies, setting their external network access permissions to Deny or limiting them to communication with necessary objects such as security modules, preventing the spread of attacks and appropriately reducing the resource quotas of these isolated containers to compensate for the increased overhead of the security modules. For the load control service (Level 1S1), its resource guarantees are maintained, but the strictest network access control list is imposed, allowing communication only with trusted dispatch console IPs. By streamlining the security policies of low-level containers, resources can be concentrated on security defense, while limiting potential attack paths to the greatest extent, ensuring the confidentiality and integrity of critical control commands, and safeguarding the network security of the power grid.

[0055] In some embodiments, the threat level It can be calculated using the following expression: ,in, Indicates the frequency of attacks. , express arrive Number of attacks within this time window This indicates the average severity of a security alarm. Abnormal values ​​representing power load control terminals can be obtained based on flow analysis algorithms or behavior analysis algorithms.

[0056] In some embodiments, weights can be assigned to the attack frequency, the average severity of security alarms, and the outliers of the power load control terminal, and normalized calculations can be performed. The adjustment expression is as follows: , This achieves the normalization of threat levels.

[0057] In some embodiments, the generated scheduling instructions are not executed immediately, but undergo a safety verification process. For example, it checks whether resource adjustments will lead to the depletion of critical system resources. The executor securely applies these instructions through the Container Runtime Interface (CRI). The engine simultaneously monitors the state changes of the container and the system after instruction execution, forming a closed-loop feedback. If resource adjustments fail to achieve the expected results (e.g., the processing latency of the load control module does not decrease after resource increases), it may trigger a recalculation of the policy or an alarm.

[0058] In some embodiments, the identification of the above-mentioned scenarios can be achieved through weighted fuzzy logic. Specifically, typical scenarios such as "peak load period," "network attack," "fault recovery," and "normal operation period" can be predefined in the business scenario library built into the power load control terminal; a scenario matching degree function can be defined for each predefined scenario. Its matching degree It is an eigenvector Each component and scene Ideal eigenvectors A function of weighted Euclidean distance (or cosine similarity), The expression can be: ,in This indicates that the k-th metric is in a predefined scenario. The weights below, Representing the eigenvector The kth component, Represents the ideal eigenvector The k-th component. It can be represented as ,when Exceeding the preset activation threshold At that time, determine the scene Activated; when multiple scenes are activated, through Determine the priority of each scenario and generate a scheduling policy based on the priority. This indicates the preset static priority.

[0059] In some embodiments, the above feature vectors and ideal eigenvectors The components include the following dimensions: CPU utilization, memory pressure index, load status index, electricity price mode, state machine model of fault handling mode, CPU queue pressure, threat level, etc.

[0060] Among them, CPU utilization This can be expressed as a weighted average of CPU utilization within a sliding time window, i.e. , This represents the total number of moments within the time window. This represents the time decay weight at time i. express CPU utilization at that time.

[0061] Memory stress index It can be represented as ,in Indicates memory usage. Indicates cache size, Indicates the total amount of memory. Indicates the weighting coefficient. This represents the page fault rate per unit of time.

[0062] Electricity price mode at time t It can be represented as ,in Indicates peak electricity price, This indicates the off-peak electricity price. This represents the on-price electricity price. The electricity price mode reflects the degree of supply and demand tension in the power system and the economic objectives of dispatch strategies.

[0063] State machine model for fault handling modes It can be represented as ,in Indicates a normal state. Indicates a high load condition. This indicates a state of attack. Indicates a restored state.

[0064] CPU queue pressure It can be represented as ,in Indicates the number of commands to be processed. This indicates the maximum capacity of the queue. This represents the sum of the waiting times for all commands in the queue. This indicates the command timeout period. CPU queue pressure reflects the real-time performance and backlog risk of terminal processing of console commands. If the queue is too long or commands wait for too long, it may cause control commands to fail (e.g., delayed load shedding can no longer prevent overload).

[0065] In some embodiments, the above multi-dimensional components can be normalized to obtain the final result. .

[0066] In some embodiments, when the power load control terminal recovers from a fault (the power load control terminal returns to normal), the containers described in L3 are restarted in batches to gradually restore the computing resources of the containers described in L1 and L2.

[0067] For example, when a power grid suffers a fault such as a line short circuit, the power system may suspend a large number of non-core services to ensure core control capabilities. After the power system returns to normal operation, it enters the recovery and reconstruction phase, where the core of its scheduling strategy is orderliness and shock mitigation. For L3-level containers (such as data backup and log upload) that were suspended during the fault, the strategy engine will not immediately restart them all, but will adopt a "batch processing" strategy. For example, it defines restarting two containers per batch, with a 30-second delay between batches, and monitors the system load. This approach avoids the "surge" impact on the system caused by a large number of containers starting simultaneously. For L2-level containers that have been downgraded (such as edge computing analytics), their resource quotas are gradually restored to standard values. For L1 containers whose resources were increased during the fault, their resource guarantees are smoothly rolled back to normal levels, and resources are released. Under the premise of ensuring overall system stability, full-function services are automatically and smoothly restored, realizing intelligent operation and maintenance and reducing the pressure of manual operation.

[0068] In some embodiments, when multiple scenarios are activated simultaneously, the policy engine will make intelligent decisions.

[0069] For example, when a power load control terminal simultaneously faces peak load periods and a cyberattack, a high load condition requires increased computing resources for L1-level containers, while a high threat level requires increased resources for S2-level containers. However, the power load control terminal has limited computing resources. In this case, the strategy of prioritizing adjustments to certain containers can be determined by calculating the final decision priority of the two scenarios (which is jointly determined by scenario matching and preset static priorities). Typically, the static priority of "peak load periods" (ensuring the physical security of the power grid) is higher than that of "cyberattacks," thus limiting the increase in computing resources for L1-level containers.

[0070] In the embodiments of this disclosure, when a deployment request for any microservice is received, a preliminary evaluation is first performed to determine whether the microservice is allowed to be deployed on the power load control terminal.

[0071] In some embodiments, when the power load control terminal receives a deployment request for any microservice, it parses the service level and security level data carried in the request to obtain the microservice's requirements. These requirements represent the resources needed to deploy the container of the microservice, and can be represented by a vector. , This indicates the primary computing resource (e.g., the number of CPU cores or share of computing power). This represents the first memory resource (the size of the memory it occupies) and the first storage resource (the required storage space).

[0072] The power load control terminal also needs to collect local resources, which represent currently available resources. These resources can be represented by a vector. , This refers to the second computing resource (such as the number or share of available CPU cores). This represents the second memory resource (the size of available memory) and the second storage resource (the available storage space).

[0073] Introducing the degree of resource fragmentation and system load pressure As an auxiliary decision-making factor, F can be represented by the ratio of the size of continuously available memory blocks in the power load control terminal to the total available memory. The larger the value of F, the lower the degree of fragmentation. It can be defined as the average length of the CPU running queue of the power load control terminal within a preset time window (i.e., a recent period). This is achieved by introducing F and... This allows the preliminary judgment to consider not only the static remaining resources of the power load control terminal, but also the dynamic resource status, thereby improving the accuracy of the feasibility judgment results.

[0074] Therefore, the first health status of the power load control terminal can be expressed as: ; in, , and Represents the weighting coefficients, satisfying It can be dynamically adjusted according to the actual situation.

[0075] The first health score characterizes the overall capability of the power load control terminal to accept containers corresponding to new microservices. A lower first health score indicates more strained available resources. When the first health score is greater than a first threshold, it indicates sufficient available resources, good performance, and low load pressure. When the first health score is less than a second threshold, it indicates limited available resources, or even if sufficient resources are available, poor performance due to high load or fragmentation. As a proactive and rapid risk assessment indicator, the first health score can be used for initial screening and optimization in the decision-making process, avoiding unnecessary complex calculations when the system is in extremely poor condition.

[0076] Preliminary judgments are made based on the first health status, the needs of microservices, and the resources of the power load control terminal.

[0077] The judgment results can be divided into four categories: In the first scenario, where the first health level is greater than the first threshold and each component of the microservice's demand vector is less than each component of the power load control terminal's resource vector (i.e., the first computing power resource is less than the second computing power resource, the first memory resource is less than the second memory resource, and the first storage resource is less than the second storage resource), the microservice is allowed to be deployed on the power load control terminal. In this case, the power load control terminal has sufficient available resources and good performance, allowing for the deployment of new containers without priority judgment.

[0078] In the second scenario, if the first health level is less than the second threshold and the microservice is of low priority, there is no need to compare the components, and the microservice is not allowed to be deployed on the power load control terminal. In this case, the power load control terminal is in poor condition and unsuitable for deploying new containers, and the microservice is of low priority and not of high importance. Therefore, there is no need to further sacrifice the performance of the power load control terminal or affect the operation of already deployed containers to deploy the container corresponding to the microservice.

[0079] In the third case, if the first health level is lower than the first threshold (between the first and second thresholds or below the thresholds) but the microservice is of high priority, then considering the high priority of the microservice, the resources of the low-priority containers already deployed on the power load control terminal can be preempted based on the preemption mechanism to ensure the normal operation of the power load control terminal and the power system.

[0080] In the fourth scenario, if the first health level is between the first and second thresholds and the microservice is of medium priority, then wait for the power load control terminal to release available resources. During operation, a running container may naturally terminate and release resources. The container corresponding to the microservice can be deployed after sufficient resources are available. In some embodiments, a time window can also be set; if deployment is not completed within the time window, deployment is abandoned.

[0081] By screening based on the first health level, we can avoid detailed resource checks (only the first case requires checking the comparison of each component of demand and resources), which reduces risk and improves decision-making efficiency.

[0082] In some embodiments, the above priority can be obtained based on service level and security level, expressed as: ; in, The service level is indicated and can be divided into L1, L2, and L3. Security levels are indicated and can be categorized into S1, S2, and S3. and These represent the weighting coefficients corresponding to the business level and security level, respectively. .

[0083] The reasons why the weighting coefficient for business level is greater than that for security level include the following aspects: Firstly, the impact of power service performance is more direct and objective. The power system is a physical entity, and its stable operation is directly related to social production and people's lives. The consequences of service interruption are immediate and physical. For example, if load control commands (L1 power services) are delayed or lost due to insufficient resources, it may lead to switch failures or malfunctions, instantly causing line overloads, equipment damage, or even large-scale power outages—physical safety accidents. These consequences are irreversible. In contrast, the consequences of security threats are usually indirect and logical. For example, although the failure of a security module (S2 power services) (such as the cracking of encrypted data) may lead to data leakage and command tampering, this threat usually takes some time to translate into physical impact, and the power system has other layers of defense (such as signature verification and network isolation) as a buffer.

[0084] Secondly, ensuring the continuity of power services is the highest-level security objective of the power system, which depends on the performance of these services. Service level (L) defines the importance of the "protected object." L1 power services (such as load control) are themselves the core assets most in need of protection. Security level (S) defines the strength of the "protection measures." S1 or S2 power services (such as encryption) are the means used to protect these core service assets. Only after ensuring the core services (L1 power services) are operational can we discuss applying security protection (S1 / S2 power services). If the resource weight of security modules is too high, causing the core services to be unable to obtain sufficient resources and thus interrupted, then the protection measures lose their protected object, which is putting the cart before the horse. For example, encryption operations should not consume too much CPU, preventing load control commands from being executed in a timely manner.

[0085] Thirdly, it achieves the inherent correlation and closed loop of model design. A high service level usually implies a high security level: an L1 power service (such as load control execution), due to the extremely serious consequences of its failure, will inevitably be assigned a high security level (S1). That is, L1 level modules are usually also S1 level. Weight differences serve to "break the tie": when two containers request resources, if their priority scores are close, The settings ensure that business criticality is the ultimate deciding factor. For example, a (L2,S3) container and a (L3,S2) container may have similar scores, but because L has a higher weight, the system will prioritize the (L2,S3) container with the higher business criticality.

[0086] Fourthly, it aligns with the actual application scenarios of power systems. Security threats are handled through specialized scenarios: in the "multi-dimensional situational indicators" of the dynamic scheduling model, network security indicators are collected and evaluated separately. When a network attack is detected, the system triggers a specialized security scenario policy, dynamically adjusting the resources of the security module. This means that the importance of security is strengthened in another dimension (situational awareness), rather than simply competing with business for priority in the single stage of deployment access. Furthermore, the "default security" of microservices is guaranteed through image building: high-business-level images have already been built with strong security policies (such as non-root, read-only file systems). Therefore, during deployment, its basic security is already guaranteed, and the focus of decision-making can be placed on dealing with dynamically changing business pressures.

[0087] The characteristics of business level and security level are shown in the table below for comparison.

[0088]

[0089] In some embodiments, the above preemption mechanism may be as follows: screening at least one candidate container based on the service level of the container already deployed on the power load control terminal; obtaining the preemption cost of the candidate container based on its priority, resource consumption, and service terminal cost; iteratively eliminating the candidate container with the lowest preemption cost until the allowability value of the microservice is greater than a first threshold; and deploying the container corresponding to the microservice on the power load control terminal based on the container image file.

[0090] This preemption mechanism can generate a preemption scheme with the minimum preemption cost, which can be expressed as: ; in, Indicates the priority of microservices. Indicates the power load control terminal number The priority of each container Indicates the power load control terminal number The resources occupied by each container Indicates the power load control terminal number The business interruption cost of each container. Containers with the lowest priority, moderate resource consumption, and low interruption cost are selected based on preemption cost.

[0091] In some embodiments, the aforementioned service interruption cost can be set by comprehensively considering factors such as whether the container is stateful and the importance of the container. When the container is a stateful service, its ability to support state preservation and recovery can also be considered.

[0092] Specifically, based on whether containers are stateful, services can be categorized into stateless services and stateful services. Stateless services do not maintain local state or session information; requests can be processed by any instance of the same container. Examples include simple RESTful API gateways, stateless compute tasks, and log forwarders. Interrupting these containers only results in the loss of a very small number of currently processed requests, and restarting a new instance allows for quick recovery. The interruption cost can be set to a low base value (e.g., 1). Stateful services maintain the container's critical state in local memory or disk (such as databases, caches, ongoing long transactions, and intermediate results from edge computing). Examples include local time-series databases, real-time data aggregation modules, and edge computing containers performing complex analyses. Interrupting these containers can lead to data loss, transaction interruptions, and state inconsistencies; therefore, the interruption cost for these containers is much higher than for stateless services (e.g., 5, 10, or higher).

[0093] Whether a service is stateful or stateless, its containers differ significantly.

[0094] The importance of containers can be correlated with service completion. For example, both are L3-level batch data backup tasks. One service is 95% complete, while the other is only 1%. It's understandable that the first container is more important than the second because removing the container and restarting the service requires re-execution, wasting the computing resources previously used to execute the service. Obviously, the former would waste more computing resources.

[0095] The importance of containers can also be related to dependencies between services. For example, if a container has a calling relationship with other containers to jointly implement a certain power service, preemption of that container will cause cascading effects. Therefore, even if a container itself has a low priority, its interruption cost can still be very high when it has a cascading relationship with other containers.

[0096] In some embodiments, for stateful services, the interruption cost of their containers also depends on whether and how they support state saving and recovery. If state saving and recovery are not supported, or if their state is stored in volatile memory, preempting the container means that its state will likely be completely lost. Restarting the service of that container will require a complete re-execution, wasting the resources consumed by the previous execution of the service, resulting in a high interruption cost. For containers that periodically save state snapshots to persistent storage (such as local terminal storage or network storage), further evaluation of their recovery point objective (the interval from the last checkpoint to the present) and recovery time objective (the time required to recover the service from the checkpoint) is needed. The longer the interval from the last checkpoint to the present, the more unsaved data there will be, and the more data may be lost when restarting the service, resulting in a higher interruption cost. The longer the time required to recover the container from the checkpoint, the longer the business interruption time, and the higher the interruption cost.

[0097] In some embodiments, the quantification process of the interruption cost of any container can be as follows: First, based on whether the container is a stateful or stateless service, the basic cost of the container is obtained. For example, if it is a stateless service, the interruption cost is initially set to 1, and if it is a stateful service, it is set to 10. For stateful services, the interruption cost is increased based on their recovery point target and recovery time target. The increased interruption cost can be the ratio of the recovery point target to 60 plus the recovery time target. Then, the interruption cost of the container is increased based on the service progress. The increased interruption cost can be 1 plus the progress value (for example, for a service with a progress of 90%, the interruption cost of its container is increased by 1.9). Finally, the interruption cost is increased based on the cascading relationship between the container and other containers. The increased interruption cost can be determined according to user settings.

[0098] In some embodiments, the interruption cost obtained at each step can be multiplied together to obtain the final interruption cost.

[0099] By performing the above steps, the interruption cost of all containers in the power load control terminal can be determined. To deploy high-priority containers, the container with the lowest interruption cost is removed one at a time until the power load control terminal has sufficient space and good performance to deploy the high-priority container.

[0100] For example, the power load control terminal currently has two low-priority containers, A and B, deployed. It now needs to preempt the resources of either container A or container B to deploy a high-priority container C.

[0101] Container A's task is a log uploader, which is a stateless service with a progress of 0%. It has no cascading relationship with other containers, and its interruption cost is ultimately determined to be 10.

[0102] Container B's task is an edge data analysis container, which is a stateful service. Its recovery point and recovery time targets are relatively small, its progress is 80%, and it has no cascading relationship with other containers. Its interruption cost was ultimately determined to be 24.

[0103] Since the interruption cost of container A is less than that of container B, container A can be removed first based on the preemption mechanism.

[0104] In some embodiments, a hibernation or stop command can be sent to the preempted container, and a brief graceful termination time window T can be waited for. grace If the container does not exit automatically within the specified time, it will be forcibly terminated.

[0105] In some embodiments, for stateful services, an attempt is made to checkpoint their state to persistent storage.

[0106] In some embodiments, the method further includes performing a second health check on the containers deployed on the power load control terminal and performing container self-healing when the second health of the container is low.

[0107] In some embodiments, a second health level of the container can be calculated based on the process status, available resources, message output frequency, and business logic of the container deployed on the power load control terminal; the business logic indicates whether it can respond normally to lightweight simulation requests; in response to the second health level being lower than the fifth threshold, the business level of the container is determined; in response to an L1 container, the container is immediately restarted or deployed to an adjacent power load control terminal; in response to an L2 container, the container is restarted within a preset time window based on the load of the power load control terminal; in response to an L3 container, the container is restarted based on the load of the power load control terminal.

[0108] Specifically, the second health of the c-th container at time t. It can be represented as: ; This represents the basic health of the c-th container at time t. It can be quantified based on whether the process is running normally and whether it is terminated by the kernel due to resource exhaustion. It is 1 when the process is normal and there is no memory overflow, and 0 otherwise. This represents the business health of the c-th container at time t. , Indicates the preset period. Indicates the maximum allowed timeout period. Indicates the time interval since the last correct report; and Indicates the weighting coefficient. .

[0109] For L1 level containers, due to their importance, the goal once a failure is detected is to restore service in the shortest possible time. Immediate and rapid restarts can be performed; to reduce restart time, a "hot standby" image of the container instance can be pre-configured or a minimal pre-boot environment can be maintained. If a restart fails after exceeding a threshold, or if the resources of the power control terminal are insufficient to support the operation of the L1 container, the container can be deployed to an adjacent power control terminal. The migration process should carry the most recent runtime state snapshot (checkpoint) whenever possible to minimize state loss.

[0110] For L2 level containers, brief service interruptions are permissible, but eventual recovery must be ensured. This can be achieved by waiting a short time window (e.g., 30 seconds) to observe system load. If system load is high, restarting can be postponed to avoid competing for resources with L1 services. Subsequently, when resources allow, restarting can be performed locally on the terminal or according to policies issued by the main station.

[0111] Level 3 containers are not sensitive to interruptions, and their recovery strategy prioritizes conserving terminal resources and network bandwidth. Instead of immediate self-processing, Level 3 containers can have their fault information (container ID, fault time, fault type) recorded. Then, during system downtime (such as during nighttime network off-peak hours) or when a certain number of terminals have available resources, batch restart or redeployment commands are executed. This batch processing approach avoids the impact of frequent, sporadic recovery operations on network and terminal resources.

[0112] In some embodiments, after the self-healing action is executed, the system continuously monitors whether the container has successfully recovered, i.e., whether its secondary health level has rebounded and stabilized within the normal range. Key metrics for each self-healing event are recorded, such as the time from the occurrence of the failure to full recovery and the amount of data loss. This data is fed back to the management platform to evaluate the effectiveness of the self-healing strategy and serves as the basis for optimizing the self-healing strategy (such as adjusting the restart timeout and migration threshold), forming a closed loop of continuous improvement.

[0113] The following uses an embodiment of this disclosure as an example to further illustrate the dynamic strategy adjustment in the technical solution of this disclosure.

[0114] Deploy the following containers at the power load control terminal: load control execution container (level L1S1), data acquisition container (level L2S2), security encryption container (level L2S2), edge real-time line loss analysis container (level L2S2), and operation log upload container (level L3S3).

[0115] The power load control terminal is preset with the following parameters: "when the load status value of the power load control terminal..." When the situation is deemed an "emergency scenario during peak load," the rule is that "L1S1 container resources must be prioritized."

[0116] When a large factory in the power system suddenly starts up high-power equipment, the total active power P of the power grid in that area... actual A sharp increase. Load status value of the power load control terminal. Calculations showed that the load value climbed from 0.75 to 0.92 within ten seconds, exceeding the preset threshold of 0.85.

[0117] The current multidimensional feature vector V is calculated in real time and matched with the scene database to determine the degree of matching with the "peak load period" scene. Rapidly exceeding the activation threshold .

[0118] At this point, the CPU share guarantee for the load control execution container is increased by 50%, from 200mCPU to 300mCPU, and its scheduling priority is set to the highest. An instruction is issued to the edge real-time line loss analysis container to reduce its CPU share limit by 40% and decrease its computation frequency. Simultaneously, a "pause" instruction is issued to the runtime log upload container, immediately releasing the CPU and memory resources it occupies.

[0119] Through the above actions, the power load control terminal can quickly allocate its limited computing resources to the most critical load control functions within hundreds of milliseconds, ensuring that it has the fastest response speed to deal with possible emergency control commands from the dispatch console.

[0120] The following describes the container self-healing mechanism in the present disclosure further using an embodiment as an example.

[0121] A historical data backup container at the L3S3 level in the power load control terminal failed due to resource preemption.

[0122] The power load control terminal detected the fault and initiated self-healing. Since its fault level was L3, according to the tiered self-healing strategy, it did not need to be restarted immediately. Instead, the fault information "historical data backup container failed at 14:31" was recorded and temporarily stored. Once the power system load gradually returned to normal levels and the network entered idle time, the previously failed historical data backup container was automatically restarted according to the strategy of "system idle time, low-priority tasks can be executed." This collaborative self-healing mechanism ensures absolute resource availability for core services during peak periods while automatically restoring non-core services when the system is idle, maximizing resource utilization and achieving intelligent operation and maintenance.

[0123] It is understandable that this method can be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities.

[0124] It should be noted that the methods of one or more embodiments of this disclosure can be executed by a single device, such as a computer or server. The methods of this embodiment can also be applied in a distributed scenario, where multiple devices cooperate to complete the process. In such a distributed scenario, one of these devices may execute only one or more steps of the methods of one or more embodiments of this disclosure, and the multiple devices will interact with each other to complete the method described.

[0125] It should be noted that the above description pertains to specific embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than those shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0126] Based on the same inventive concept, corresponding to any of the above-described embodiments, this disclosure also provides a container deployment device for a power load control terminal. For example... Figure 2 As shown, the device includes: The acquisition module 11 is configured to acquire multiple microservices corresponding to at least one power service of the power load control terminal; Module 12 is configured to build a container image file corresponding to the microservice based on the business level and security level of the microservice; The judgment module 13 is configured to, in response to receiving a deployment request for any of the microservices, determine whether the microservice is allowed to be deployed on the power load control terminal based on the requirements of the microservice and the resources of the power load control terminal; Deployment module 14 is configured to deploy the container corresponding to the microservice on the power load control terminal based on the container image file in response to determining that the microservice is allowed to be deployed on the power load control terminal.

[0127] Optionally, the requirements of the microservice include a first computing power resource, a first memory resource, and a first storage resource required to deploy the microservice, and the resources of the power load control terminal include a second computing power resource, a second memory resource, and a second storage resource available to the power load control terminal. Module 13 is specifically configured as follows: The first health status of the power load control terminal is obtained based on the ratio of the second computing power resource to the total computing power resource of the power load control terminal, the ratio of the second memory resource and the fragmentation value of the power load control terminal multiplied by the total memory resource of the power load control terminal, and the load of the power load control terminal. In response to the first health level being greater than the first threshold and the first computing power resource being less than the second computing power resource, the first memory resource being less than the second memory resource, and the first storage resource being less than the second storage resource, the microservice is allowed to be deployed on the power load control terminal.

[0128] Optionally, it is also configured as follows: In response to the first health level not exceeding the first threshold, the priority of the microservice is calculated based on the business level and the security level of the microservice; the priority is divided into high priority, medium priority and low priority according to the level. In response to the first health level being less than the second threshold and the microservice being of low priority, the microservice is not allowed to be deployed on the power load control terminal; In response to the first health level being between the second threshold and the first threshold and the microservice being of medium priority, wait for the power load control terminal to release available resources; In response to the microservice being of high priority, the microservice is permitted to be deployed on the power load control terminal.

[0129] Optionally, deployment module 14 is specifically configured as follows: Based on the service level of the containers already deployed on the power load control terminal, at least one candidate container is selected; The preemption cost of the candidate container is obtained based on its priority, resource consumption, and service terminal cost. Iteratively eliminate candidate containers with the lowest preemption cost until the allowability value of the microservice is greater than the first threshold. The container corresponding to the microservice is deployed on the power load control terminal based on the container image file.

[0130] Optionally, the service level includes a first service level L1, a second service level L2, and a third service level L3, and the security level includes a first security level S1, a second security level S2, and a third security level S3. Module 12 is specifically configured as follows: A minimized vulnerability image is used for the microservices of L1S1 or L1S2, a lightweight base image is used for the microservices of L1S3, L2S1 or L2S2, and a general base image is used for the microservices of L1S3, L2S1 or L2S2. An enhanced security policy is adopted for the microservices of L1S1, L1S2, L2S1 or L3S1, a standard security policy is adopted for the microservices of L1S3, L2S2 or L3S2, and a basic security policy is adopted for the microservices of L2S3 or L3S3. The microservices of L1 adopt a high resource strategy and a high real-time guarantee strategy, the microservices of L2 adopt a medium resource strategy and a medium real-time guarantee strategy, and the microservices of L3 adopt a low resource strategy and a low real-time guarantee strategy.

[0131] Optionally, it is also configured as follows: In response to the load of the power load control terminal exceeding a third threshold, the computing resources of the L1 container deployed by the power load control terminal are increased, the computing resources of the L2 container deployed by the power load control terminal are reduced, and the L3 container deployed by the power load control terminal is suspended. In response to the power load control terminal having a threat level higher than a fourth threshold, computing resources are added to the container deployed by the power load control terminal in S2 based on the threat level, and access permissions to the container deployed by the power load control terminal are tightened. In response to the power load control terminal returning to normal, the L3 container is restarted in batches, and the computing resources of the L1 and L2 containers are gradually restored.

[0132] Optionally, it is also configured as follows: The second health of the container is calculated based on its process status, available resources, message output frequency, and business logic deployed on the power load control terminal; the business logic indicates whether it can respond normally to lightweight simulation requests. In response to the second health level falling below the fifth threshold, the service level of the container is determined; In response to the container described in L1, either restart the container immediately or deploy the container to an adjacent power load control terminal; In response to the container described in L2, the container is restarted within a preset time window based on the load of the power load control terminal; In response to the container described in L3, the container is restarted according to the load of the power load control terminal.

[0133] For ease of description, the above apparatus is described in terms of its functions, divided into various modules. Of course, when implementing one or more embodiments of this disclosure, the functions of each module can be implemented in one or more software and / or hardware.

[0134] The apparatus described above is used to implement the corresponding methods in the foregoing embodiments and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0135] Figure 3This embodiment illustrates a more specific hardware structure of an electronic device. The device may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0136] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this disclosure.

[0137] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this disclosure are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0138] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0139] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0140] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0141] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this disclosure, and not necessarily all the components shown in the figures.

[0142] The electronic devices described above are used to implement the corresponding methods in the foregoing embodiments and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0143] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0144] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this disclosure (including the claims) is limited to these examples; within the framework of this disclosure, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of one or more embodiments of this disclosure as described above, which are not provided in detail for the sake of brevity.

[0145] Additionally, to simplify the description and discussion, and to avoid obscuring one or more embodiments of this disclosure, the provided drawings may or may not show well-known power / ground connections to integrated circuit (IC) chips and other components. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring one or more embodiments of this disclosure, and this also takes into account the fact that the details of implementation of these block diagram apparatuses are highly dependent on the platform on which one or more embodiments of this disclosure will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuitry) are set forth to describe exemplary embodiments of this disclosure, it will be apparent to those skilled in the art that one or more embodiments of this disclosure may be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0146] Although this disclosure has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0147] This disclosure includes one or more embodiments intended to cover all such substitutions, modifications, and variations falling within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A container deployment method for a power load control terminal, characterized in that, include: Obtain at least one power service corresponding to multiple microservices from the power load control terminal; Based on the business level and security level of the microservice, construct the container image file corresponding to the microservice; In response to receiving a deployment request for any of the microservices, the system determines whether the microservice is allowed to be deployed on the power load control terminal based on the requirements of the microservice and the resources of the power load control terminal. In response to determining that the microservice is permitted to be deployed on the power load control terminal, the container corresponding to the microservice is deployed on the power load control terminal based on the container image file.

2. The method according to claim 1, characterized in that, The requirements of the microservice include the first computing power resources, the first memory resources, and the first storage resources required to deploy the microservice, and the resources of the power load control terminal include the second computing power resources, the second memory resources, and the second storage resources available to the power load control terminal. Based on the requirements of the microservice and the resource availability of the power load control terminal, the determination of whether to allow the deployment of the microservice includes: The first health status of the power load control terminal is obtained based on the ratio of the second computing power resource to the total computing power resource of the power load control terminal, the ratio of the second memory resource and the fragmentation value of the power load control terminal multiplied by the total memory resource of the power load control terminal, and the load of the power load control terminal. In response to the first health level being greater than the first threshold and the first computing power resource being less than the second computing power resource, the first memory resource being less than the second memory resource, and the first storage resource being less than the second storage resource, the microservice is allowed to be deployed on the power load control terminal.

3. The method according to claim 2, further comprising: In response to the first health level not exceeding the first threshold, the priority of the microservice is calculated based on the business level and the security level of the microservice; The priorities are divided into high priority, medium priority and low priority according to their levels; In response to the first health level being less than the second threshold and the microservice being of low priority, the microservice is not allowed to be deployed on the power load control terminal; In response to the first health level being between the second threshold and the first threshold and the microservice being of medium priority, wait for the power load control terminal to release available resources; In response to the microservice being of high priority, the microservice is permitted to be deployed on the power load control terminal.

4. The method according to claim 3, wherein in response to the microservice being of high priority, a container corresponding to the microservice is deployed on the power load control terminal based on the container image file, comprising: Based on the service level of the containers already deployed on the power load control terminal, at least one candidate container is selected; The preemption cost of the candidate container is obtained based on its priority, resource consumption, and service terminal cost. Iteratively eliminate candidate containers with the lowest preemption cost until the allowability value of the microservice is greater than the first threshold. The container corresponding to the microservice is deployed on the power load control terminal based on the container image file.

5. The method according to claim 1, characterized in that, The service level includes a first service level L1, a second service level L2, and a third service level L3, and the security level includes a first security level S1, a second security level S2, and a third security level S3. Based on the business level and security level of the microservice, construct the container image file corresponding to the microservice, including: A minimized vulnerability image is used for the microservices of L1S1 or L1S2, a lightweight base image is used for the microservices of L1S3, L2S1 or L2S2, and a general base image is used for the microservices of L1S3, L2S1 or L2S2. An enhanced security policy is adopted for the microservices of L1S1, L1S2, L2S1 or L3S1, a standard security policy is adopted for the microservices of L1S3, L2S2 or L3S2, and a basic security policy is adopted for the microservices of L2S3 or L3S3. The microservices of L1 adopt a high resource strategy and a high real-time guarantee strategy, the microservices of L2 adopt a medium resource strategy and a medium real-time guarantee strategy, and the microservices of L3 adopt a low resource strategy and a low real-time guarantee strategy.

6. The method according to claim 5, characterized in that, Also includes: In response to the load of the power load control terminal exceeding a third threshold, the computing resources of the L1 container deployed by the power load control terminal are increased, the computing resources of the L2 container deployed by the power load control terminal are reduced, and the L3 container deployed by the power load control terminal is suspended. In response to the power load control terminal having a threat level higher than a fourth threshold, computing resources are added to the container deployed by the power load control terminal in S2 based on the threat level, and access permissions to the container deployed by the power load control terminal are tightened. In response to the power load control terminal returning to normal, the L3 container is restarted in batches, and the computing resources of the L1 and L2 containers are gradually restored.

7. The method according to claim 1, characterized in that, Also includes: The second health of the container is calculated based on its process status, available resources, message output frequency, and business logic deployed on the power load control terminal; the business logic indicates whether it can respond normally to lightweight simulation requests. In response to the second health level falling below the fifth threshold, the service level of the container is determined; In response to the container described in L1, either restart the container immediately or deploy the container to an adjacent power load control terminal; In response to the container described in L2, the container is restarted within a preset time window based on the load of the power load control terminal; In response to the container described in L3, the container is restarted according to the load of the power load control terminal.

8. A container deployment device for a power load control terminal, characterized in that, include: The acquisition module is configured to acquire multiple microservices corresponding to at least one power service of the power load control terminal; The build module is configured to build the container image file corresponding to the microservice based on the business level and security level of the microservice; The judgment module is configured to, in response to receiving a deployment request for any of the microservices, determine whether the microservice is allowed to be deployed on the power load control terminal based on the requirements of the microservice and the resources of the power load control terminal; The deployment module is configured to deploy the container corresponding to the microservice on the power load control terminal based on the container image file in response to determining that the microservice is allowed to be deployed on the power load control terminal.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executed by the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer instructions for causing the computer to perform the method of any one of claims 1 to 7.

Images