Container scheduling method and related device

Abstract

The application discloses a container scheduling method and related equipment, and relates to the technical field of computers, and the method comprises the following steps: obtaining a preset concurrent running threshold and a preset maximum instantiation threshold of a hardware device; in response to a container creation request, determining whether to create a target container according to a first comparison result of a current total number of created containers and the preset maximum instantiation threshold, and configuring the target container into a stop state after it is determined that the target container is created; and in response to a container startup request, obtaining a current number of active containers of the hardware device, and determining whether to start the target container according to a second comparison result of the current number of active containers and the preset concurrent running threshold. The application decouples container creation and running, and controls the threshold based on storage capacity and hardware concurrent capability respectively, so that the actual concurrent load is limited while the instance scale is expanded, and the balance between the improvement of resource utilization and the stability of system running can be realized without increasing the hardware cost.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a container scheduling method and related equipment. Background Technology

[0002] With the continuous development of cloud computing, edge computing, and virtualization technologies, container technology, due to its advantages such as lightweight design, rapid deployment, and high resource utilization, has been widely applied in various hardware device scenarios with limited computing power, such as cloud phones, cloud gaming, and industrial edge nodes. In these applications, a single hardware device often needs to support multiple instance business environments to meet the needs of multi-task processing or concurrent access by multiple users. Therefore, how to achieve efficient scheduling and management of container instances under limited hardware resources has become a key issue in improving the overall system performance and resource utilization.

[0003] In related technologies, container scheduling typically employs a hardware-based concurrency control strategy, binding the number of containers created to the number that can run concurrently, and controlling system load by setting a fixed concurrency limit. This approach limits the number of container instances to hardware concurrency capabilities, failing to fully utilize device storage resources, resulting in insufficient resource utilization in scenarios with a large number of non-running or low-frequency usage. Furthermore, existing scheduling methods often introduce the risk of runtime resource consumption during the creation phase, making it difficult to support flexible management of large-scale instances. When container startup requests arrive in concentrated bursts, concurrency resource contention can intensify, potentially causing instantaneous system load exceeding limits, thus affecting overall operational stability. In other words, related technologies suffer from technical problems such as limited container instance numbers, low resource utilization, and insufficient operational control precision. Summary of the Invention

[0004] In the summary section of this application, the relevant technical solutions are described in general terms, and a series of simplified concepts are introduced. These concepts will be further elaborated in the detailed embodiments section. This summary section should not be construed as limiting the key or essential technical features of the claimed solutions, nor is it intended to limit the scope of protection of the claimed solutions.

[0005] The container scheduling method and related equipment provided in this application can decouple container creation from operation and perform threshold control based on storage capacity and hardware concurrency capability respectively. While expanding the instance scale, it limits the actual concurrent load with runtime gating mechanism, and can achieve a balance between improving resource utilization and system operation stability without increasing hardware costs.

[0006] In a first aspect, this application provides a container scheduling method applied to a hardware device, comprising: obtaining a preset concurrent operation threshold and a preset maximum instantiation threshold for the hardware device, wherein the preset concurrent operation threshold is determined based on the physical concurrent processing capability of the hardware device, the preset maximum instantiation threshold is determined based on the available storage space of the hardware device, and the preset maximum instantiation threshold is greater than the preset concurrent operation threshold; in response to a container creation request, determining whether to create a target container based on a first comparison result between the total number of currently created containers and the preset maximum instantiation threshold, and configuring the target container to a stopped state after determining to create the target container; in response to a container startup request, obtaining the current number of active containers of the hardware device, and determining whether to start the target container based on a second comparison result between the current number of active containers and the preset concurrent operation threshold.

[0007] In some implementations, the step of determining whether to create a target container in response to a container creation request, based on a first comparison result between the total number of currently created containers and the preset maximum instantiation threshold, includes: obtaining a pre-configured over-configuration flag; if the over-configuration flag indicates that over-configuration mode is enabled, in response to the container creation request, obtaining the total number of currently created containers; if the total number of currently created containers is less than the preset maximum instantiation threshold, then determining to create the target container; generating a storage policy enforcement instruction for the target container based on the over-configuration flag, and modifying the storage type of the target container to a preset remote shared storage type through the storage policy enforcement instruction.

[0008] In some implementations, configuring the target container to a stopped state includes: obtaining the post-creation behavior configuration item corresponding to the target container; when the over-configuration flag indicates that the over-configuration mode is enabled, forcibly setting the automatic startup attribute in the post-creation behavior configuration item to a disabled state; and modifying the initialization script execution entry point of the target container to a null operation so that the target container is unconditionally in the stopped state after creation.

[0009] In some implementations, obtaining the number of currently active containers of the computing-constrained hardware includes: sending a status acquisition instruction to the hardware device through a gating module; receiving real-time operating data returned by the hardware device based on the status acquisition instruction, wherein the real-time operating data includes container status identifiers; and obtaining the number of currently active containers by counting the containers in the running and starting states in the real-time operating data.

[0010] In some implementations, determining whether to start the target container based on a second comparison result between the current number of active containers and the preset concurrent operation threshold includes: if the current number of active containers is less than the preset concurrent operation threshold, generating a start-allow instruction and sending the start-allow instruction to the hardware device to perform a start-up operation; if the current number of active containers is greater than or equal to the preset concurrent operation threshold, generating a start-intercept instruction and determining a number to be released based on the difference between the current number of active containers and the preset concurrent operation threshold; and generating and outputting a first prompt message based on the number to be released, wherein the first prompt message indicates the number of containers that need to be stopped.

[0011] In some implementations, after generating the start interception command, the container scheduling method further includes: obtaining a preset priority tag and a last active timestamp for each active container corresponding to the current number of active containers; filtering out a target container set from the active containers based on the preset priority tag and the last active timestamp, and generating a recommended stop list for the target container set; and outputting a second prompt message containing the recommended stop list.

[0012] In some implementations, after outputting the second prompt information, the method further includes: updating the current active container count of the hardware device in response to a stop operation instruction for at least one first container in the recommended stop list; and triggering a startup process for the target container according to a preset startup waiting queue after detecting that the updated current active container count meets preset startup conditions.

[0013] In some implementations, the container scheduling method further includes: in response to a trigger command for a batch maintenance task on the hardware device, acquiring and recording a snapshot of the pre-maintenance running state of each container on the hardware device, the snapshot including a container identifier, a running state bit, and a startup priority; after the batch maintenance task is completed, parsing the snapshot to obtain a list of containers to be restored and the startup priority corresponding to each container; sequentially selecting a second container from the list of containers to be restored and attempting to start it, according to the startup priority from high to low, until the number of successfully started containers reaches the preset concurrent running threshold; and resetting the running state bit of a third container that failed to start in the list of containers to be restored to a stopped state.

[0014] Secondly, this application also provides a container scheduling device applied to a hardware device, comprising: a data acquisition unit, configured to acquire a preset concurrent operation threshold and a preset maximum instantiation threshold for the hardware device, wherein the preset concurrent operation threshold is determined based on the physical concurrent processing capability of the hardware device, and the preset maximum instantiation threshold is determined based on the available storage space of the hardware device, and the preset maximum instantiation threshold is greater than the preset concurrent operation threshold; a container creation unit, configured to, in response to a container creation request, determine whether to create a target container based on a first comparison result between the total number of currently created containers and the preset maximum instantiation threshold, and configure the target container to a stopped state after determining to create the target container; and a container startup unit, configured to, in response to a container startup request, acquire the number of currently active containers of the hardware device, and determine whether to start the target container based on a second comparison result between the number of currently active containers and the preset concurrent operation threshold.

[0015] Thirdly, this application also provides an electronic device, including: a memory and a processor, wherein the processor is configured to implement the steps of the container scheduling method described in the first aspect when executing a computer program stored in the memory.

[0016] Fourthly, this application also provides a computer-readable storage medium storing computer-executable instructions or a computer program, which, when executed by a processor, implement the steps of the container scheduling method described in the first aspect.

[0017] Fifthly, this application also provides a computer program product, including a computer program or computer executable instructions, wherein when the computer program or computer executable instructions are executed by a processor, the steps of the container scheduling method provided in the embodiments of this application are implemented.

[0018] In summary, this application obtains a concurrent operation threshold determined based on hardware physical concurrency capabilities and a maximum instantiation threshold determined based on storage space during the initial scheduling phase. It explicitly states that both thresholds satisfy the condition that the maximum instantiation threshold is greater than the concurrent operation threshold. This enables differentiated modeling of computing and storage resources, allowing the number of container instances to be constrained by storage capacity rather than hardware concurrency capabilities. This increases the total number of container instances that a device can support without altering hardware physical performance, thus improving resource utilization. During the container creation phase, the first comparison between the total number of currently created containers and the maximum instantiation threshold determines whether to create a container. After creation, the container is configured to a stopped state. Therefore, the creation process does not directly introduce runtime load, as newly created containers do not participate in resource contention by default, thus avoiding instantaneous computing power consumption caused by batch creation operations. The addition of new containers allows the system to maintain operational load stability while expanding instance size. During container startup, the system obtains the current number of active containers and compares it with a concurrency threshold before deciding whether to start a container. This creates a real-time state-based control process. New containers are only allowed to start when the number of active containers has not reached the hardware's capacity limit; otherwise, they are restricted from starting. This ensures that the actual number of running containers at any given time never exceeds the hardware's physical concurrency capacity, thus avoiding resource overload and improving system stability. Expanding instance size without introducing load during creation and imposing strict constraints based on real-time operational status during startup ensures the system has both high instance capacity and precise control over runtime resources. This achieves a balance between instance expansion and operational stability while ensuring hardware safety. In summary, the container scheduling method provided in this application decouples container creation and operation, and uses threshold control based on storage capacity and hardware concurrency capacity respectively. By expanding instance size while limiting actual concurrent load through runtime gating mechanisms, it achieves a balance between improved resource utilization and system stability without increasing hardware costs. Attached Figure Description

[0019] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating a container scheduling method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the composition structure of a container scheduling device provided in an embodiment of this application; Figure 3This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] The terms used in the specification, claims, and drawings of this application, such as "first," "second," "third," "fourth," etc. (if any), are used to distinguish similar objects and not to describe a specific order or sequence. Therefore, it is to be understood that these terms can be used interchangeably where appropriate, allowing the described embodiments to be used in different orders, unless specifically required by the illustrations or description. Furthermore, the terms "is" and "has," and any variations thereof, are intended to cover, non-exclusively, all possible constituent elements. For example, a process, method, system, product, or apparatus comprising several steps or units is not necessarily limited to the steps or units explicitly listed, but may also include other steps or units not explicitly listed, or steps or units inherent to the process, method, product, or apparatus.

[0021] In this application, a "module" or "unit" refers to a computer program or part of a computer program that has a specific function and works in conjunction with other related parts to achieve a predetermined goal. These modules or units can be implemented by software, hardware (e.g., processing circuitry or memory), or a combination of both. One or more processors or memories can implement one or more modules or units. Furthermore, each module or unit can also be part of a larger module or unit.

[0022] The technical solutions of this application will be described in detail below with reference to the accompanying drawings of the embodiments. It should be noted that the described embodiments are only a part of this application, and not all embodiments. In the following description, the "some embodiments" mentioned are only a subset of all possible embodiments, which may be the same or different subsets, and different embodiments can be combined with each other without conflict.

[0023] Figure 1 This is a flowchart illustrating a container scheduling method provided in an embodiment of this application. For example, see [link to example]. Figure 1The container scheduling method provided in this application is applied to hardware devices. Hardware devices are physical devices used to support the operation of container instances and provide computing and storage resources. They serve as the application carrier for the container scheduling method and may include computing-constrained hardware such as System-on-Chips (SoCs) and Edge Computing Nodes (ECNs). These hardware devices have a defined upper limit on their physical resources and cannot support the concurrent operation and storage of container instances without limitation. They are the core object of resource management during container scheduling. For example, the scheduling system (SS) can read the hardware parameters of the SoC through the Peripheral Component Interconnect (PCI) interface to confirm that it is a hardware device suitable for the application of this scheduling method. The container scheduling method may include the following steps 101 to 103: Step 101: Obtain the preset concurrent operation threshold and the preset maximum instantiation threshold for the hardware device. The preset concurrent operation threshold is determined based on the physical concurrent processing capability of the hardware device, and the preset maximum instantiation threshold is determined based on the available storage space of the hardware device. The preset maximum instantiation threshold is greater than the preset concurrent operation threshold.

[0024] In some examples, the preset concurrent execution threshold is a pre-configured maximum number of container instances that the hardware device can stably support running concurrently. This threshold is the core criterion for concurrency management during container startup. Its value is always a positive integer and matches the actual operating capacity of the hardware device, ensuring that the hardware device will not experience overload, crashes, or other abnormalities when operating within this threshold range. The preset concurrent execution threshold is determined based on the physical concurrent processing capacity of the hardware device. Physical concurrent processing capacity is the maximum number of container tasks that the hardware device can process simultaneously per unit of time, determined by the hardware parameters of the hardware device, primarily including the number of Central Processing Unit (CPU) cores, memory bandwidth, and Graphics Processing Unit (GPU) parameters. Key metrics such as CPU core count (CPU), GPU computing power, etc., directly determine the number of container instances that a hardware device can stably run simultaneously, eliminating the possibility of arbitrary subjective configuration. There are two main ways to obtain the preset concurrent running threshold: one is automatic detection by the scheduling system. After the hardware device is connected, the scheduling system uses resource detection tools to comprehensively detect the physical parameters of the hardware device, such as the number of CPU cores, memory bandwidth, and GPU computing power. Combined with a preset parameter-threshold mapping algorithm, it automatically calculates and generates the preset concurrent running threshold. The other is manual configuration by the administrator. The administrator manually inputs the preset concurrent running threshold through the scheduling system's configuration interface, based on the hardware device's factory parameters, actual operating test data, and business scenario requirements. For example, if a SoC board has an 8-core CPU, 16GB of memory, and a GPU computing power of 100 GFLOPS, the scheduling system automatically detects and calculates that its physical concurrent processing capability corresponds to a preset concurrent running threshold of 6, meaning that the SoC board can stably run a maximum of 6 container instances simultaneously. If the administrator finds through actual business testing that the board performs best when running 6 container instances simultaneously, they can also manually configure the preset concurrent running threshold to 6.

[0025] The preset maximum instantiation threshold is a pre-configured maximum number of container instances that the hardware device can support. This threshold is used as the basis for capacity access checks during the container creation phase. Its value is always a positive integer and greater than the preset concurrent running threshold. It is used to decouple the container creation state from the running state, allowing for the creation of more container instances. The preset maximum instantiation threshold is determined based on the available storage space of the hardware device. Available storage space refers to the remaining storage space in the hardware device used to store container images, container configuration files, container runtime data, and other related content. Its size directly determines the maximum number of container instances that the hardware device can create. The creation process of container instances will occupy a certain amount of storage space, and the creation of container instances cannot be completed when the available storage space is insufficient. The method for obtaining the preset maximum instantiation threshold is the same as that for the preset concurrent running threshold, which is divided into automatic and automatic. There are two methods for obtaining the data: detection and manual configuration. After the hardware device is connected, the scheduling system uses a storage detection tool to read the total storage space and occupied storage space of the hardware device, calculates the available storage space, and then combines this with the average storage space occupied by a single container instance to automatically calculate and generate a preset maximum instantiation threshold. Administrators can also manually configure the preset maximum instantiation threshold based on the available storage space of the hardware device and the storage requirements of a single container instance. For example, if the available storage space of the above SoC board is 100GB and the average storage space occupied by a single container instance is 5GB, the scheduling system automatically calculates a preset maximum instantiation threshold of 20. Administrators can also manually configure the preset maximum instantiation threshold to 20 based on the need for multi-account cold backup in business scenarios to ensure that the board can create 20 container instances, meeting the need for over-creation.

[0026] For example, after completing the access and identification of hardware devices, the scheduling system immediately initiates a resource detection process to comprehensively detect the physical concurrent processing capabilities and available storage space of the hardware devices. The system calculates the corresponding preset concurrent operation threshold and preset maximum instantiation threshold using a preset algorithm, and verifies the relationship between the two thresholds to ensure that the preset maximum instantiation threshold is greater than the preset concurrent operation threshold. If the verification fails, the preset maximum instantiation threshold is automatically adjusted to a reasonable range. If the verification passes, the two thresholds are stored in the scheduling system's configuration database, completing the acquisition and initialization of the thresholds and providing a basis for judgment in the processing of subsequent container creation and startup requests.

[0027] By implementing step 101, the concurrent operation threshold determined based on the hardware physical concurrent processing capability and the maximum instantiation threshold determined based on the available storage space are obtained respectively, and the maximum instantiation threshold is limited to be greater than the concurrent operation threshold, thereby realizing the distinction and constraint of computing resources and storage resources. This allows the creation scale of container instances to break through the limitation of hardware concurrent processing capability and instead be controlled by storage capacity, thereby expanding the number of instances that can be created without changing hardware performance and improving the overall resource utilization range.

[0028] Step 102: In response to the container creation request, determine whether to create the target container based on the first comparison result between the total number of currently created containers and the preset maximum instantiation threshold, and configure the target container to a stopped state after determining to create the target container.

[0029] In some examples, a container creation request is an instruction to request the creation of a container instance on a hardware device. It triggers the container creation process and can be initiated by a user through a terminal device or automatically by a business system based on preset business requirements. The container creation request contains basic configuration information related to the container, mainly including the container name, container image identifier, and basic resource specifications required by the container. Its format must conform to the communication protocol preset by the scheduling system to ensure that the scheduling system can correctly parse and respond. The scheduling system can listen in real time through a preset communication interface. When a creation request is sent to the scheduling system, the scheduling system immediately receives the request and performs preliminary verification of the request format and content. After the verification is successful, it proceeds to the subsequent processing flow. For example, a user enters the container name "CTR-001", selects a preset container image, and clicks the create button through the container management interface of a terminal device. The terminal device sends a container creation request to the scheduling system, which receives the request through the Transmission Control Protocol (TCP) interface, completing the acquisition and preliminary verification of the request.

[0030] The total number of currently created containers is the number of all container instances successfully created on the hardware device up to the time the container creation request is received. This count includes all containers in the "created" state, regardless of whether they are currently running or stopped. It does not include container instances that are being created or have failed to be created. This data is used for capacity access checks. The scheduling system can query its own container management database in real time. This database records the creation status, identification information, and other data of all container instances on the hardware device. By executing a query command, the scheduling system counts the number of container instances in the database with the status "created," thus obtaining the total number of currently created containers. For example, if 15 container instances have been successfully created on the hardware device, of which 6 are running and 9 are stopped, the scheduling system will find that the total number of currently created containers is 15 after querying the container management database.

[0031] The first comparison result is obtained by comparing the total number of currently created containers with the preset maximum instantiation threshold. It is used to determine whether the storage space of the hardware device can support the creation of new container instances and is the basis for determining whether to create the target container. The total number of currently created containers obtained by querying can be compared with the preset maximum instantiation threshold obtained and stored in step 101 to generate three possible comparison results: the total number of currently created containers is less than the preset maximum instantiation threshold, the total number of currently created containers is equal to the preset maximum instantiation threshold, and the total number of currently created containers is greater than the preset maximum instantiation threshold. For example, if the preset maximum instantiation threshold is 20 and the total number of currently created containers is 15, the first comparison result obtained by the scheduling system through the comparison algorithm is that the total number of currently created containers is less than the preset maximum instantiation threshold; if the total number of currently created containers is 20, the first comparison result is that the two are equal; if the total number of currently created containers is 21, the first comparison result is that the total number of currently created containers is greater than the preset maximum instantiation threshold.

[0032] The target container is the container instance to be created, as indicated by the current container creation request. It is the object of the container creation process. Each container creation request corresponds to a target container. After creation, the target container is assigned a unique container identifier for subsequent status management, startup, shutdown, and other operations. The system can parse the container creation request, extract the container configuration information from the request, generate the initialization parameters of the target container based on the configuration information, and determine the specific specifications and attributes of the target container. For example, the scheduling system parses the container creation request sent by the user, extracts information such as the container name "CTR-001" and the container image identifier, predefines the specifications of the target container based on this information, and after creation, the target container becomes the 16th container instance on the hardware device and is assigned the unique identifier "CTR-001".

[0033] The process of determining whether to create a target container based on the first comparison result between the total number of currently created containers and the preset maximum instantiation threshold is the judgment logic in step 102. Its core principle is to determine whether the available storage space of the hardware device can support the creation of a new container instance. In the specific implementation process, after obtaining the first comparison result, the judgment operation is performed according to the preset judgment rules: if the first comparison result is that the total number of currently created containers is less than the preset maximum instantiation threshold, it means that the hardware device has sufficient storage space for creating new container instances, and at this time, the target container is determined to be created; if the first comparison result is that the total number of currently created containers is equal to or greater than the preset maximum instantiation threshold, it means that the storage space of the hardware device cannot support the creation of new container instances, and at this time, the target container is determined not to be created, and a creation failure prompt message is returned to the request initiator; for example, if the preset maximum instantiation threshold is 20, the total number of currently created containers is 15, and the first comparison result is that the former is greater than the latter, the scheduling system determines to create the target container; if the total number of currently created containers is 20 or 21, the scheduling system determines not to create the target container and returns the prompt "Insufficient storage space, unable to create container".

[0034] After determining the target container to be created, the process of configuring the target container to a stopped state involves the scheduling system immediately initializing the target container's running state after triggering the target container creation process and completing the target container creation operation. This ensures that the target container is in a stopped state and does not occupy the computing resources of the hardware device. In specific implementation, a state configuration command can be sent to the hardware device, explicitly specifying that the target container's running state is stopped. After receiving the command, the hardware device executes the state configuration operation, sets the target container's running state identifier to stopped, and synchronizes this state to the scheduling system's container management database, completing the target container's state configuration. For example, after the scheduling system determines to create the target container "CTR-001", it sends a state configuration command to the SoC board, requiring "CTR-001" to be configured to a stopped state. After the SoC board executes the command, it sets the container's running state to stopped and synchronously updates the scheduling system's container management database, ensuring that the scheduling system can obtain the target container's state in real time.

[0035] By implementing step 102, during the container creation phase, the decision to create a container is made solely based on the first comparison result between the total number of currently created containers and the maximum instantiation threshold. After creation, the container is configured to be in a stopped state, so that the creation behavior does not immediately introduce runtime load. This avoids the increase in instantaneous computing power resource consumption caused by batch container creation, thereby maintaining the stability of system runtime load while supporting large-scale instance creation.

[0036] Step 103: In response to the container startup request, obtain the current number of active containers on the hardware device, and determine whether to start the target container based on the second comparison result between the current number of active containers and the preset concurrent running threshold.

[0037] In some examples, a container start request is an instruction used to request the startup and execution of a container instance already created on a hardware device. It triggers the container startup process, and the initiator is the same as the container creation request. It can be initiated manually by the user through a terminal device or automatically by the business system according to business scheduling needs. The container start request contains a unique container identifier for the container to be started, used by the scheduling system to accurately locate the container instance to be started. Its format must conform to the scheduling system's preset communication protocol to ensure that the scheduling system can correctly parse and respond. The scheduling system can listen in real-time through a preset communication interface, which is the same as the interface used to obtain container creation requests. When a container start request is sent to the scheduling system, the scheduling system first performs a preliminary verification of the request format and the legality of the container identifier. After the verification is successful, it proceeds to the subsequent startup control process. For example, a user selects a container with the identifier "CTR-001" through the container management interface on a terminal device and clicks the start button. The terminal device sends a container start request to the scheduling system. The scheduling system receives the request through the Transmission Control Protocol interface, verifies the legality of the container identifier, and then proceeds to the subsequent steps of startup control.

[0038] The current number of active containers is the total number of container instances in the running and startup states on the hardware device as of the time the container startup request is received. This number directly reflects the current computing power utilization of the hardware device and does not include container instances in the stopped, destroyed, or created states. It serves as the data basis for concurrency management during the startup phase. A status query command can be sent to the hardware device. After receiving the command, the hardware device collects the real-time running status of all its container instances, filters out the container instances in the running and startup states, counts them, and returns the count results as real-time running data to the scheduling system. After receiving this data, the scheduling system can obtain the current number of active containers. For example, if 20 container instances have been created on the hardware device, of which 5 are in the running state, 1 is in the startup state, and 14 are in the stopped state, after the scheduling system sends a status query command to the hardware device and receives the returned real-time running data, the current number of active containers is counted as 6.

[0039] The second comparison result is obtained by comparing the current number of active containers with a preset concurrent operation threshold. It is used to determine whether the computing power resources of the current hardware device are sufficient to support the startup and operation of the target container, and is the basis for determining whether to start the target container. The current number of active containers obtained from the hardware device can be compared with the preset concurrent operation threshold obtained and stored in the configuration database in step 101 to generate three possible comparison results: the current number of active containers is less than the preset concurrent operation threshold, the current number of active containers is equal to the preset concurrent operation threshold, and the current number of active containers is greater than the preset concurrent operation threshold. For example, if the preset concurrent operation threshold determined in step 101 is 6 and the current number of active containers is 5, the second comparison result obtained by the scheduling system through the comparison algorithm is that the current number of active containers is less than the preset concurrent operation threshold; if the current number of active containers is 6, the second comparison result is that the two are equal; if the current number of active containers is 7, the second comparison result is that the current number of active containers is greater than the preset concurrent operation threshold.

[0040] The process of determining whether to start a target container based on the second comparison result between the current number of active containers and the preset concurrent operation threshold involves performing a judgment operation according to preset judgment rules after obtaining the second comparison result: If the second comparison result shows that the current number of active containers is less than the preset concurrent operation threshold, it means that the hardware device still has remaining computing power resources to support the start of the target container, and the target container is determined to be started; if the second comparison result shows that the current number of active containers is equal to or greater than the preset concurrent operation threshold, it means that the computing power resources of the hardware device have reached their carrying capacity limit and cannot support the start of new container instances, and the target container is determined not to be started, and a startup failure prompt message is returned to the request initiator; for example, if the preset concurrent operation threshold is 6, the current number of active containers is 5, and the second comparison result shows that the former is greater than the latter, the scheduling system determines to start the target container; if the current number of active containers is 6 or 7, the scheduling system determines not to start the target container and returns a prompt message "Computing power resources are full, container cannot be started".

[0041] By implementing step 103, the number of currently active containers is obtained during the container startup phase, and a decision is made on whether to start the container based on the second comparison result with the concurrent running threshold, forming a dynamic control mechanism based on real-time running status. This ensures that the number of containers actually running at any given time does not exceed the physical concurrent processing capacity limit of the hardware device, thereby effectively preventing resource overload and improving the stability and reliability of system operation.

[0042] In summary, the embodiments of this application obtain the concurrent operation threshold determined based on the hardware's physical concurrency capability and the maximum instantiation threshold determined based on storage space during the initial scheduling phase. It is explicitly stated that both satisfy the condition that the maximum instantiation threshold is greater than the concurrent operation threshold. This enables differentiated modeling of computing and storage resources, allowing the number of container instances to be constrained by storage capacity rather than hardware concurrency capabilities. This increases the total number of container instances that can be supported on the device without altering hardware physical performance, thereby improving resource utilization. During the container creation phase, the first comparison between the total number of currently created containers and the maximum instantiation threshold determines whether to create a container. After creation, the container is configured to a stopped state. Therefore, the creation behavior does not directly introduce runtime load, as newly created containers do not participate in resource contention by default, thus avoiding instantaneous computing power loss due to batch creation operations. The increased resource consumption allows the system to maintain stable runtime load while expanding instance size. During container startup, the system obtains the current number of active containers and compares it with a concurrency threshold before deciding whether to start a container. This creates a real-time state-based control process. New containers are only allowed to start when the number of active containers has not reached the hardware's capacity limit; otherwise, they are restricted from starting. This ensures that the actual number of running containers at any given time never exceeds the hardware's physical concurrency capacity, thus avoiding resource overload and improving system stability. Expanding instance size without introducing load during creation and imposing strict constraints based on real-time runtime status during startup allows the system to have both high instance capacity and precise control over runtime resources. This achieves a balance between instance expansion and operational stability while ensuring hardware safety. In summary, the container scheduling method provided in this application decouples container creation and operation, and uses threshold control based on storage capacity and hardware concurrency capacity respectively. By expanding instance size while limiting actual concurrent load through runtime gating mechanisms, it achieves a balance between improved resource utilization and system stability without increasing hardware costs.

[0043] In some embodiments, the aforementioned determination of whether to create a target container in response to a container creation request, based on a first comparison result between the total number of currently created containers and a preset maximum instantiation threshold, may include: obtaining a pre-configured over-configuration flag; if the over-configuration flag indicates that over-configuration mode is enabled, obtaining the total number of currently created containers in response to a container creation request; if the total number of currently created containers is less than the preset maximum instantiation threshold, determining to create a target container; generating a storage policy enforcement instruction for the target container based on the over-configuration flag, and modifying the storage type of the target container to a preset remote shared storage type through the storage policy enforcement instruction.

[0044] In some examples, the over-capacity flag is a pre-configured binary status indicator parameter in the scheduling system. It is a core global configuration item specifically used to indicate whether the dedicated control mode for container over-capacity creation is enabled. It is the basis for distinguishing between the normal creation mode and the over-capacity creation mode. This parameter does not participate in the computing power control during the container runtime phase, but only affects the access and configuration logic during the container creation phase. The over-capacity flag can be manually set by the administrator through the scheduling system's visual configuration interface during the system initialization phase. After configuration, it is stored in the scheduling system's configuration database. When the scheduling system responds to a container creation request, it directly reads the real-time status of this flag from the database. For example, the over-capacity flag is set as a Boolean parameter, which is assigned a valid status when the over-capacity mode is enabled and an invalid status when disabled. For edge computing nodes that carry multi-account carousel services, the administrator can manually configure this flag to a valid status to activate the over-capacity creation logic.

[0045] Excess mode is a container creation management mode triggered by the excess configuration flag. Its purpose is to break the traditional strong binding restriction between the number of containers created and the hardware's concurrent operation capacity. It uses only the available storage space of the hardware device as the criterion, allowing the creation of container instances far exceeding the hardware's concurrent operation threshold. This is suitable for business scenarios involving multiple container cold backups and round-robin usage. This mode only takes effect when the excess configuration flag is valid and has no independent triggering path. For example, a system-level chip board has a preset concurrent operation threshold of 6 and a preset maximum instantiation threshold of 20. After enabling excess mode, container creation is no longer limited by the concurrent operation threshold; it only needs to meet the storage capacity requirement to create 20 containers, unlike the limitation of only 6 containers in normal mode. When the excess configuration flag indicates that excess mode is enabled, the system responds to the container... The container creation request, which retrieves the total number of currently created containers, is a prerequisite step for the creation admission verification in over-limit mode. Its core logic is that the scheduling system first determines the validity of the mode, then initiates the container count process. Admission verification, which is only associated with the maximum instantiation threshold, is only executed after the mode is enabled, completely circumventing the constraints of concurrent operation thresholds on the creation process. The method for obtaining the total number of currently created containers is consistent with the normal creation mode. The scheduling system queries the container management database to count the number of all created container instances on the hardware device, excluding container running status and only counting the total number of successfully created instances. For example, after the over-limit configuration flag is determined to be valid and over-limit mode is enabled, the scheduling system receives a container creation request and then queries the database to obtain a total of 18 currently created containers, providing data support for subsequent threshold comparisons.

[0046] Storage policy enforcement instructions are storage configuration instruction messages with the highest execution priority generated by the scheduling system for overcapacity mode. These instructions are generated autonomously by the scheduling system without manual intervention and can forcibly override the container's default local storage configuration. This prevents excessive container creation from crowding out local hardware storage space and avoids creation failures or system anomalies caused by local storage overflow. The scheduling system can automatically generate these instructions through its built-in instruction compilation module after confirming that overcapacity mode is enabled and container creation conditions are met. The instructions carry parameters such as the target container's unique identifier and the target storage type, and are directly sent to the storage management unit of the hardware device for execution. For example, the scheduling system generates a dedicated storage policy enforcement instruction for the target container to be created, explicitly specifying the storage type modification rules. The hardware device must execute this instruction first and cannot skip or modify its content. Pre-defined remote shared storage types are remote network storage types that are pre-configured in the scheduling system and are distinct from local hardware storage. They rely on remote storage hardware and network communication protocols to store container data, completely eliminating the need for local hardware storage. This is a standardized storage type adapted to the overcapacity mode's overcapacity creation requirements. Common remote shared storage implementations include network attached storage. Storage (NAS) and Storage Area Network (SAN); this storage type can be configured by the administrator in advance during the system initialization phase, including address configuration, communication protocol binding, and mount permission settings for remote storage devices, thus solidifying it as the default storage type for the overcapacity mode of the scheduling system. The scheduling system can directly call this configuration parameter; for example, the administrator sets the preset remote network auxiliary storage as the dedicated storage for the overcapacity mode, and the hardware local storage only reserves basic resources for running containers. Containers created beyond the limit all rely on this remote storage to complete data storage.

[0047] Based on the over-configuration flag, a mandatory storage policy instruction is generated for the target container. This instruction then modifies the target container's storage type to a preset remote shared storage type. In over-configuration mode, after recognizing the over-configuration flag as valid, the storage management module triggers the instruction generation process. The generated instruction is then directly sent to the hardware device's storage management unit. Upon receiving the instruction, the unit skips the container's default local storage allocation process and automatically switches the target container's image storage and data storage path to the preset remote shared storage. This entire process is closed-loop and requires no manual intervention. For example, after the scheduling system confirms that over-configuration mode is enabled, it generates a corresponding mandatory instruction for target containers that meet the creation conditions. This instruction is sent to the system-level chip board's storage management unit, which immediately changes the target container's storage type from the default local storage to the preset remote network-attached storage type, completely releasing local storage resources.

[0048] By implementing the above embodiments, setting an over-configuration flag and controlling creation solely based on the maximum instantiation threshold when enabling over-configuration mode, while forcibly adjusting the container storage type to remote shared storage, the expansion of container instances no longer depends on local storage resources. This not only further increases the number of containers that can be created and alleviates local resource bottlenecks, but also improves resource reuse capabilities through a centralized storage strategy, thereby effectively improving overall resource utilization and providing support for large-scale instance management.

[0049] In some embodiments, configuring the target container to a stopped state may include: obtaining the post-creation behavior configuration item corresponding to the target container; when the over-configuration flag indicates that over-configuration mode is enabled, forcibly setting the automatic startup attribute in the post-creation behavior configuration item to a disabled state; and modifying the initialization script execution entry point of the target container to a null operation so that the target container is unconditionally stopped after creation.

[0050] In some examples, post-creation behavior configuration items are a set of parameters in the target container's initialization configuration. These items are specifically designed to define the actions the target container will automatically perform after creation. They contain multiple configurable attributes, with automatic startup being one of the most crucial. This directly determines whether the target container will automatically start and run after creation. Each configuration item corresponds one-to-one with the target container and is generated synchronously with its creation. The scheduling system, after determining the target container to be created, can parse the configuration parameters in the container creation request and, combined with the scheduling system's preset container basic configuration template, generate post-creation behavior configuration items corresponding to the target container. These configuration items are then stored in the container management database for later querying and modification. For example, for a target container identified as "CTR-002," after parsing the creation request, the scheduling system generates post-creation behavior configuration items containing automatic startup attributes, startup delay attributes, etc. The automatic startup attribute is set to enabled by default, meaning the container will automatically start after creation in normal mode.

[0051] When the over-configuration flag indicates that over-configuration mode is enabled, forcibly setting the automatic startup attribute in the post-creation behavior configuration item to disabled is the first layer of protection for the target container's stop status configuration in over-configuration mode. That is, the forced modification operation of the automatic startup attribute is only triggered when the over-configuration flag is in a valid state and over-configuration mode is officially enabled. This operation is not performed in normal mode, ensuring that containers created in excess will not start automatically due to the default configuration, thus avoiding the occupation of computing resources. In the implementation process, after generating the post-creation behavior configuration item for the target container, the scheduling system first reads the real-time status of the over-configuration flag from the configuration database. If it is determined that over-configuration mode is enabled, the configuration modification interface is called to forcibly change the automatic startup attribute in the post-creation behavior configuration item from the default enabled state to the disabled state. After the modification is completed, it is synchronously updated to the container management database to ensure that the configuration takes effect. For example, after a system-level chip board enables over-configuration mode, the scheduling system forcibly sets the automatic startup attribute in the post-creation behavior configuration item of the target container to be created to the disabled state. Even if the container creation request specifies automatic startup as enabled, it will be overridden by this forced operation to ensure that the container will not start automatically after creation.

[0052] Modifying the target container's initialization script execution entry point to an empty operation is the second layer of protection in the target container's stopped state configuration under overload mode. This prevents the target container from automatically starting after creation at the underlying execution logic level, mitigating potential control vulnerabilities from simply modifying the automatic startup attribute. The initialization script is the startup script that executes automatically after the target container is created. It contains instructions for environment initialization and service startup required for container operation. The initialization script's execution entry point is its trigger path; modifying it to an empty operation cancels this trigger path, preventing the initialization script from executing and thus ensuring the target container cannot start automatically. In the specific implementation, this can be handled by a scheduler. After forcibly disabling the automatic power-on attribute, the system locates the initialization script execution entry address of the target container through the container configuration interface, calls the script modification instruction, and modifies the execution instruction corresponding to the entry address to empty, that is, does not perform any initialization operation. After the modification is completed, a configuration synchronization instruction is sent to the hardware device to ensure that the hardware device synchronizes the configuration. For example, if the scheduling system locates the initialization script execution entry point of the target container "CTR-002" as " / init / start.sh", it sets the execution logic of the entry point to empty by modifying the instruction. Even if the automatic power-on attribute is accidentally tampered with, the initialization script cannot be triggered to execute, and the target container will remain in a stopped state.

[0053] By implementing the above embodiments, the automatic startup behavior after container creation is forcibly disabled in overload mode, and the initialization script is modified to keep the container in a stopped state after creation. This mechanism can avoid coupling between the creation operation and the running load, thereby preventing the introduction of instantaneous concurrent pressure when creating containers in batches, reducing the risk of system load fluctuations, and enabling the system to maintain the stability of its running state while expanding the scale of instances, thereby improving the controllability and security of the scheduling process.

[0054] In some embodiments, obtaining the current number of active containers of the computing-limited hardware may include: sending a status acquisition instruction to the hardware device through a gating module; receiving real-time running data returned by the hardware device based on the status acquisition instruction, wherein the real-time running data may include container status identifiers; and obtaining the current number of active containers by counting the containers in the running and startup states in the real-time running data.

[0055] In some examples, the gating module (GM) is a core functional module deployed independently within the scheduling system. It is specifically designed to perform concurrency control operations during the container startup phase and serves as a crucial intermediary module connecting the scheduling system and hardware devices. It does not participate in the management logic during the container creation phase. The gating module's responsibilities include receiving active container count query commands from the scheduling system, generating and sending status acquisition commands to the hardware devices, receiving real-time running data returned by the hardware devices, parsing the data, and completing active container count statistics. This provides accurate data support for subsequent container startup gating decisions. For instance, for edge computing nodes equipped with a container scheduling system, technicians bind the gating module to the main scheduling system module during system deployment to ensure that the gating module can receive scheduling commands normally, establish stable communication with the hardware devices, and guarantee the smooth execution of the current active container count acquisition process.

[0056] The status acquisition command is a message generated by the gating module after receiving an active quantity query command from the scheduling system and sent to the hardware device to request the real-time running status of containers. This command has a fixed format and communication protocol, including parameters such as hardware device identifier, query range, and data return requirements, ensuring that the hardware device can accurately parse and respond. The gating module can receive the active quantity query command from the scheduling system and automatically compile and generate the status acquisition command according to a preset command format using its built-in command generation unit. After generation, the command is sent to the corresponding hardware device through a preset communication interface. For example, after receiving a query command from the scheduling system to check the number of active containers on a system-on-a-chip (SoC) board, the gating module immediately generates a status acquisition command. The command clearly identifies the unique device of the SoC board and requests the return of real-time status data for all containers on the board. This command is then sent to the SoC board through the transmission control protocol interface.

[0057] Real-time runtime data is a dataset containing the real-time runtime status of all container instances, collected by the hardware device based on status acquisition commands and returned to the gating module. This data reflects the real-time operation of each container on the hardware device and is the data source for counting the number of currently active containers. The standardization of its data format and content directly determines the accuracy of the counting results. After receiving the status acquisition command sent by the gating module, the hardware device can collect the real-time runtime status of all created containers one by one through its own container status acquisition unit. After organizing the collected status data according to a preset format, it is fed back to the gating module through the communication interface corresponding to the gating module. For example, after receiving the status acquisition command, the SoC board collects the real-time status of 20 created containers on the board, organizes it into a dataset containing container identifiers, container statuses, and other information, and returns it to the gating module as real-time runtime data to ensure that the gating module can completely obtain the status information of all containers.

[0058] Container status identifiers are unique identifiers used in real-time runtime data to characterize the current running status of a single container instance. They are an integral part of the real-time runtime data, with each container instance corresponding to a unique status identifier. These identifiers use a standardized coding format to clearly distinguish different running states of the container, providing a clear basis for filtering and counting active containers. When collecting real-time container running status data, hardware devices can automatically assign a corresponding standardized status identifier to each container based on its actual state (running, starting, stopping, stopped, etc.), and return this identifier to the gating module along with the real-time runtime data. For example, a two-digit code can be used as the container status identifier, where "01" indicates the container is running, "02" indicates the container is starting, and "03" indicates the container is stopped. When the hardware device detects a container in a running state, it assigns it the "01" identifier, which is then fed back to the gating module along with the real-time runtime data.

[0059] Container instances that meet the definition of an active state can be filtered from real-time running data. The accurate number of active instances is obtained through counting operations, ensuring that the data can truly reflect the current computing power usage of the hardware device. In specific implementation, after the gating module receives the real-time running data returned by the hardware device, it uses the built-in data parsing unit to parse each container status identifier in the data one by one, filtering out container instances whose status is running or starting. Then, the built-in counting unit counts the number of the filtered container instances. The value obtained after the count is the current number of active containers. For example, after the gating module parses the real-time running data, it filters out 5 containers with the container status identifier "01" (running) and 1 container with the identifier "02" (starting). The counting unit counts the current number of active containers as 6. This value corresponds to the preset concurrent running threshold of the hardware device, providing data support for subsequent startup gating judgment.

[0060] Through the implementation of the above embodiments, the gating module obtains real-time operating data from the hardware device and performs a unified count of running and startup containers based on the container status identifier to obtain the current number of active containers. This achieves accurate perception of the system's operating status, thereby avoiding errors caused by relying on static configuration or estimation, improving the accuracy of operating status judgment, providing a reliable basis for subsequent startup decisions, and thus improving the precision of operation control.

[0061] In some embodiments, determining whether to start a target container based on the second comparison result between the current number of active containers and a preset concurrent operation threshold may include: if the current number of active containers is less than the preset concurrent operation threshold, generating a start-allow instruction and sending the start-allow instruction to the hardware device to perform the start-up operation; if the current number of active containers is greater than or equal to the preset concurrent operation threshold, generating a start-intercept instruction and determining the number to be released based on the difference between the current number of active containers and the preset concurrent operation threshold; and generating and outputting a first prompt message based on the number to be released, the first prompt message indicating the number of containers that need to be stopped.

[0062] In some examples, the startup permission instruction is a message generated by the gating module when it determines that the hardware device has remaining computing resources. This instruction is used to allow the target container to start. It has a fixed format and the highest execution priority, and includes parameters such as the unique identifier of the target container and startup timing requirements. It is specifically used to trigger the hardware device to execute the startup operation of the target container and is the instruction basis for the target container to start normally. The built-in instruction generation unit can automatically compile and generate the startup permission instruction after determining that the number of currently active containers is less than the preset concurrent running threshold. After the instruction is generated, it is synchronously stored in the instruction log library for easy subsequent traceability and verification. For example, the preset concurrent running threshold of a certain system-level chip board is 6, and the number of currently active containers is 5. After the gating module determines that the startup conditions are met, it automatically generates a startup permission instruction for the target container "CTR-003". The instruction clearly marks the identifier and startup priority of the container, ensuring that the hardware device can accurately locate and start the target container.

[0063] The startup operation is a series of specific operations performed by a hardware device after receiving a startup permission command to switch a target container from a stopped state to a running state. These operations may include allocating computing resources to the target container, loading the container image, initializing the runtime environment, and starting services inside the container, ultimately enabling the target container to start running normally and perform corresponding business tasks. For example, after receiving the startup permission command, the SoC board allocates dedicated CPU cores and memory resources to the target container "CTR-003", loads the container image and completes runtime environment initialization, starts business services inside the container, and so on until the container switches to a running state, completing the startup operation.

[0064] After the gating module compares the current number of active containers with the preset concurrent operation threshold, if it determines that the current number of active containers is less than the preset concurrent operation threshold, it immediately triggers the generation process of a start-allow instruction. After the instruction is generated, it is sent to the corresponding hardware device through the transmission control protocol interface. After receiving the instruction, the hardware device automatically executes the start operation and simultaneously feeds back the start progress to the gating module. The gating module then synchronizes the relevant information to the scheduling system. For example, if the preset concurrent operation threshold is 6 and the current number of active containers is 5, the gating module determines that the difference between the two is 1, indicating that there is remaining computing power. It then generates a start-allow instruction and sends it to the SoC board. After receiving the instruction, the SoC board executes the start operation, switching the target container from the stopped state to the running state. After the start is completed, it synchronously feeds back the start success information, and the gating module updates the current number of active containers to 6.

[0065] The startup interception command is a message generated by the gating module when it determines that the hardware device's computing power resources have reached their capacity limit. It is used to intercept the startup request of a target container. This command has the same format as the startup allow command but functions inversely. Its purpose is to prevent the hardware device from executing the startup operation of the target container, avoiding system crashes and service anomalies due to computing power overload. It is a computing power protection command. The built-in command generation unit can automatically compile and generate a startup interception command after determining that the number of currently active containers is greater than or equal to a preset concurrent running threshold. The command clearly indicates the reason for interception and related prompts. After generation, it is synchronously stored in the command log library, simultaneously triggering the subsequent calculation process for the number of containers to be released. For example, if the preset concurrent running threshold is 6, and the number of currently active containers is 6 or 7, the gating module determines that the hardware computing power has reached its limit and immediately generates a startup interception command, clearly stating "Computing power resources are full, starting new containers is prohibited," providing a basis for the generation of subsequent prompt information.

[0066] The quantity to be released is the portion of the current number of active containers that exceeds the preset concurrent operation threshold. It is the difference between the current number of active containers and the preset concurrent operation threshold. This value is a non-negative integer and is used to explicitly inform the user how many running containers need to be stopped to release sufficient computing resources to start the target container. After generating the start interception command, the built-in numerical calculation unit subtracts the preset concurrent operation threshold from the current number of active containers. The difference is the quantity to be released. If the current number of active containers equals the preset concurrent operation threshold, the difference is 0, and the quantity to be released is 0. For example, if the preset concurrent operation threshold is 6 and the current number of active containers is 7, the gating module calculates 7 minus 6 to obtain a difference of 1, determining the quantity to be released to be 1. If the current number of active containers is 6, the calculated difference is 0, and the quantity to be released is 0. In this case, the user needs to stop at least 0 containers (i.e., no containers need to be stopped; only the existing containers need to be stopped to release resources).

[0067] After the gating module completes the second comparison result determination, if it determines that the number of currently active containers is greater than or equal to the preset concurrent operation threshold, it immediately generates a start interception command to prevent the hardware device from performing the start operation. Then, it calls the numerical calculation unit to calculate the difference between the number of currently active containers and the preset concurrent operation threshold. This difference is used as the quantity to be released and stored in the data cache area to provide data support for the generation of the subsequent first prompt information. For example, if the preset concurrent operation threshold is 6 and the number of currently active containers is 8, the gating module determines that the interception condition is met. After generating the start interception command, it calculates 8 minus 6 to get the difference 2, determines that the quantity to be released is 2, and clarifies that the user needs to stop 2 running containers before starting the target container.

[0068] The first prompt message is generated by the gating module based on the number of containers to be released. It clearly instructs the user to stop the number of containers to be stopped. This message includes the number of containers to be released, the reason for the stoppage, and operational instructions. Its format is concise and clear, easily recognizable by users or business systems. Its purpose is to provide users with clear resource release guidance, helping them quickly complete the operation to start the target container. After determining the number of containers to be released, the first prompt message is automatically generated by the built-in information generation unit, using a preset prompt message template. The number of containers to be released is embedded in the template, and the generated message is synchronously stored in the information log database. For example, when the number of containers to be released is 1, the first prompt message reads, "The current hardware device's computing resources are full. One running container needs to be stopped to release computing resources before the target container can be started." When the number of containers to be released is 2, the first prompt message reads, "The current hardware device's computing resources are full. Two running containers need to be stopped to release computing resources before the target container can be started."

[0069] After the gating module generates the first prompt message, it can send the prompt message to the initiator of the container start request through the communication interface of the scheduling system. The initiator can be a user terminal device or a business system. After receiving the prompt message, the user or business system can perform the corresponding container stop operation according to the prompt. For example, after the gating module determines that the number to be released is 1, it generates the corresponding first prompt message and sends the message to the container management interface of the user terminal through the scheduling system. After viewing the prompt message on the interface, the user can understand that one running container needs to be stopped, and then perform the stop operation to release computing resources.

[0070] For example, after receiving a user's startup request for the target container "CTR-003", the scheduling system sends a query command to the gating module to check the number of currently active containers. After data collection and statistics, the gating module finds that the number of currently active containers is 7, and reads the preset concurrent operation threshold of 6 from the configuration database. The gating module compares the two and determines that the number of currently active containers is greater than the preset concurrent operation threshold. It immediately generates a startup interception command and calculates the difference between 7 and 6 through the numerical calculation unit to determine that the number to be released is 1. Then, based on the number to be released, the gating module generates a first prompt message and sends it to the user terminal through the scheduling system, informing the user that one running container needs to be stopped. If the number of currently active containers corresponding to the user's startup request is 5, the gating module determines that it is less than the preset concurrent operation threshold, generates a startup permission command and sends it to the SoC board. The SoC board executes the startup operation, switches the target container to the running state, and synchronously feeds back startup success information. The entire process realizes differentiated control of startup requests, which not only ensures the stable operation of hardware devices, but also provides clear operation guidance for users.

[0071] By implementing the above embodiments, the startup decision distinguishes between two control paths: "allow startup" and "intercept startup". In the case of interception, the number of containers to be released is determined based on the threshold difference and a prompt message is output. This enables the system to have a clear feedback mechanism while ensuring the concurrency limit. This not only prevents resource overload but also guides users to release resources reasonably, improves the operability and fineness of resource scheduling, and thus improves the operation control effect.

[0072] In some embodiments, after generating the aforementioned startup interception instruction, the container scheduling method may further include: obtaining the preset priority label and last active timestamp of each active container corresponding to the current number of active containers; filtering out a target container set from each active container based on the preset priority label and last active timestamp, and generating a recommended stop list for the target container set; and outputting a second prompt message containing the recommended stop list.

[0073] In some examples, the preset priority label is a pre-configured identifier for each container, representing the importance of the container's business operations. It directly determines the container's running priority; the higher the priority, the more likely it is to retain its running state. The last active timestamp records the time when each active container last performed a business operation or updated its status, representing the container's activity level. The earlier the timestamp, the lower the container's activity level, and the more suitable it is to be stopped. The preset priority label can be pre-configured and assigned values ​​by the administrator or business system based on the importance of the business operations carried by the container during container creation. After configuration, it is stored in the container management database and can be retrieved by querying the container identifier. The last active timestamp can be collected in real-time by hardware devices to monitor the business execution status of each active container. The system records the time of each status update and associates the time information with the container identifier for easy querying and retrieval. For example, among the 7 active containers on a system-on-a-chip board, 3 containers have a preset priority tag of "high" and carry core business, while 4 containers have a preset priority tag of "low" and carry non-core cold backup business. Among the containers with the tag "low", the last active timestamp of container "CTR-004" is 9:00 on the same day, the last active timestamp of container "CTR-005" is 10:30 on the same day, and the last active timestamp of the other two low-priority containers is 14:00 on the same day. The preset priority tags and last active timestamps of all active containers can be obtained by querying the container management database and hardware feedback data.

[0074] The target container set is a collection of container instances recommended for user shutdown, selected by the gating module from all active containers based on preset priority tags and last active timestamps. The number of containers in this set is exactly the same as the number to be released. All containers in the set are non-core, low-activity containers, and their shutdown will not affect the normal operation of core businesses. It serves as the data source for generating the recommended shutdown list. After determining the number to be released, all active containers can be sorted and filtered based on preset filtering rules to select container instances that meet the conditions and form the target container set. After filtering, this set is stored in the data cache for subsequent generation of the recommended shutdown list. For example, when the number to be released is 1, the gating module selects one container "CTR-004" with a preset priority tag of "low" and the earliest last active timestamp from 7 active containers to form the target container set. If the number to be released is 2, then two containers "CTR-004" and "CTR-005" with preset priority tags of "low" and the earliest last active timestamps are selected to form the target container set.

[0075] The recommended stop list is a list generated by the gating module based on the target container set. It contains detailed information about all recommended stop containers. This list clearly presents the information of each recommended stop container, facilitating quick identification, selection, and execution of the stop operation by the user. It serves as a key link between the target container set and user actions. After the target container set is generated, the built-in list generation unit extracts information from each container within the set, including the container's unique identifier, preset priority tag, and last active timestamp. This information is then organized into a list according to a preset format, generating the recommended stop list. The list is synchronously stored in the log database for later traceability. For example, if the target container set contains container "CTR-004", the recommended stop list would read: "Recommended stop container: CTR-004; Preset priority tag: Low; Last active time: 9:00 AM today". If the target container set contains both "CTR-004" and "CTR-005", the list is sorted by the last active timestamp, presenting the relevant information for both containers in a clear and intuitive manner.

[0076] The second prompt message, generated by the gating module, includes a recommended stop list and related operation instructions. Building upon the first prompt message, it adds specific information about the recommended containers to be stopped. Unlike the first prompt message, which only indicates the number of containers to be released, this provides users with more precise and specific operation guidance, further reducing the difficulty of user operation. After generating the recommended stop list, the built-in information generation unit can embed the recommended stop list into a preset prompt message template, while simultaneously adding operation instructions, reasons for interception, etc., automatically generating the second prompt message. This information is then synchronously stored in the information log database. For example, if the number of containers to be released is 1 and the recommended stop list includes "CTR-004", the second prompt message would read: "The current hardware device's computing power resources are full. One running container needs to be stopped to release computing power resources; Recommended stop container list: CTR-004 (Priority: Low, Last active time: 9:00 AM today); Please select a recommended container or manually select another low-priority container to perform the stop operation. After completion, a restart request can be initiated again."

[0077] By implementing the above embodiments, introducing preset priority tags and last active timestamps, filtering currently active containers and generating a recommended stop list, intelligent auxiliary decision-making for the resource release process can be achieved. This avoids disordered or inefficient manual selection, prioritizes the release of low-priority or low-activity containers, improves the rationality and efficiency of resource release, and further enhances the overall intelligence level of system scheduling and the precision of operation control.

[0078] In some embodiments, after outputting the aforementioned second prompt information, the method may further include: updating the current active container count of the hardware device in response to a stop operation instruction for at least one first container in the recommended stop list; and triggering a startup process for the target container according to a preset startup waiting queue after detecting that the updated current active container count meets preset startup conditions.

[0079] In some examples, the first container is a container instance selected by the user or business system from the recommended stop list and subjected to a stop operation. It belongs to the recommended stop list and has the characteristics of low preset priority and low activity. Stopping it will not affect the normal operation of core business. It is the specific object that the user chooses to stop to release computing resources. Each first container corresponds to a unique container identifier, one-to-one with the containers in the recommended stop list. After receiving the stop operation command issued by the user or business system, the container identifier in the command can be parsed to confirm that the container identifier belongs to the recommended stop list, thus identifying the container as the first container. Simultaneously, the gating module verifies the container's current active state by querying the container management database, ensuring the validity of the stop operation. For example, if the recommended stop list contains containers "CTR-004" and "CTR-005", and the user selects container "CTR-004" and issues a stop operation command through the container management interface of the terminal device, the gating module parses the container identifier "CTR-004" in the command, confirms that it belongs to the recommended stop list and is currently active, thus identifying "CTR-004" as the first container corresponding to this stop operation.

[0080] The gating module receives stop operation commands for at least one first container from users or business systems via the communication interface of the scheduling system. After parsing the first container identifier in the command, it sends the stop operation command to the corresponding hardware device. Upon receiving the command, the hardware device executes the stop operation on the first container, switching it from an active state (running or starting) to a stopped state. After completing the stop operation, it feeds back the stop result and the updated container status data to the gating module. Upon receiving the feedback data, the gating module uses its built-in counting update unit to decrement the current number of active containers (stopping one first container decrements the active count by one). (If multiple containers are stopped, the corresponding number of containers will be reduced). After the update is completed, the new number of currently active containers is stored in the data cache and synchronously updated to the container management database to ensure data consistency. For example, if the number of currently active containers is 7 and the preset concurrent running threshold is 6, the user issues a stop operation command for the first container "CTR-004". The gating module sends the command to the system-on-a-chip board. The SoC board executes the stop operation, switches "CTR-004" to the stopped state, and feeds back the result. After receiving the feedback, the gating module updates the number of currently active containers from 7 to 6 and synchronously stores it in the data cache and container management database to complete the data update.

[0081] After detecting that the updated number of currently active containers meets the preset startup conditions, the startup process for the target container is triggered according to the preset startup waiting queue. This is a closed-loop execution logic of startup after stopping operations. Its purpose is to automatically trigger the startup process of the container to be started after the computing resources are released, without requiring the user to manually re-initiate the startup request, thereby improving the level of scheduling automation and ensuring the orderliness of the startup process. The preset startup conditions are conditions pre-configured in the scheduling system to determine whether to allow the startup of the target container. This condition can be that the updated number of currently active containers is less than the preset concurrent running threshold. This condition is the sole criterion for triggering the startup process and does not involve any other additional conditions. The preset startup waiting queue is a queue structure pre-configured in the scheduling system to store the target containers to be started. When the startup request of the target container is intercepted, the scheduling system will automatically add the identifier and related configuration information of the target container to the startup waiting queue. The queue adopts a "first-in, first-out" sorting rule to ensure the orderliness of startup requests. The startup waiting queue can automatically add the relevant information of the target container to the preset startup waiting queue when the startup interception command is generated. The queue information is stored in the memory of the scheduling system for easy and fast retrieval.

[0082] For example, after the gating module sends a second prompt message containing a recommended stop list to the user terminal, the user views the prompt message, selects the first container "CTR-004" in the recommended stop list, and sends a stop operation command through the terminal device. After receiving the command, the gating module parses and confirms that "CTR-004" is the first container, and sends the stop operation command to the SoC board through the transmission control protocol interface. The SoC board executes the stop operation, switches "CTR-004" to the stop state, and feeds back the operation result. After receiving the feedback, the gating module updates the number of currently active containers from 7 to 6, and then triggers a preset start condition detection, comparing and finding the updated... The number of active containers equals the preset concurrent running threshold of 6, which does not meet the startup conditions, so the startup process is not triggered. The user then stops another first container "CTR-005" in the recommended stop list. The gating module updates the current number of active containers to 5 again, detects that the preset startup conditions are met, immediately extracts the information of the target container "CTR-003" from the startup waiting queue, generates a startup permission instruction and sends it to the SoC board, triggering the startup process. The SoC board performs the startup operation, switches "CTR-003" to the running state, and completes the startup closed loop after the stop operation. This achieves efficient utilization of computing resources and reduces manual operation by the user.

[0083] Through the implementation of the above embodiments, the number of active containers is dynamically updated after the user performs a stop operation, and the target container startup process is automatically triggered in combination with the preset startup waiting queue when the startup conditions are met. This realizes the linkage mechanism between resource release and task execution, thereby reducing repetitive manual operations, improving the continuity and automation of the scheduling process, and enabling the system to efficiently complete container switching and operation scheduling under resource-constrained conditions.

[0084] In some embodiments, the aforementioned container scheduling method may further include: in response to a triggering instruction for a batch maintenance task on a hardware device, acquiring and recording a snapshot of the pre-maintenance running state of each container on the hardware device, wherein the pre-maintenance running state snapshot may include a container identifier, a running state bit, and a startup priority; after the batch maintenance task is completed, parsing the pre-maintenance running state snapshot to obtain a list of containers to be restored and the startup priority of each container; sequentially selecting a second container from the list of containers to be restored in descending order of startup priority to attempt to start it, until the number of containers that have successfully started reaches a preset concurrent running threshold; and resetting the running state bit of a third container that has failed to start in the list of containers to be restored to a stopped state.

[0085] In some examples, batch maintenance tasks are unified maintenance operations executed centrally on multiple container instances already created on hardware devices. Their purpose is to improve maintenance efficiency and reduce manual operation costs. They cover various maintenance types, including container firmware updates, vulnerability patching, and unified adjustment of configuration parameters. This task can apply to multiple containers simultaneously, unlike individual maintenance operations targeting a single container. Administrators can initiate these tasks by selecting the hardware devices and corresponding containers to be maintained and configuring the task type and parameters through the maintenance management interface of the scheduling system. Alternatively, business systems can automatically initiate batch maintenance tasks for target hardware devices based on preset maintenance cycles. For example, an administrator might initiate a batch firmware update task for 20 container instances on an edge computing node, simultaneously performing firmware updates on all 20 containers – this is a batch maintenance task. Another example is a business system automatically initiating a batch vulnerability patching maintenance task for all containers on a system-level chip board on a weekly basis.

[0086] Trigger commands are instruction messages used to initiate batch operation and maintenance (O&M) tasks. Their function is to trigger the scheduling system and gating module to execute batch O&M-related operations. They contain core information such as batch O&M task type, O&M scope (target hardware devices and containers), and O&M parameters, and are the sole trigger for initiating batch O&M tasks. When an administrator initiates a batch O&M task, the scheduling system receives the user's operation instruction through the O&M management interface and automatically compiles and generates the trigger command. When a business system initiates an O&M task automatically, the system's built-in O&M scheduling unit generates the trigger command according to a preset cycle. After the trigger command is generated, it is sent by the scheduling system to the gating module, which then initiates the pre-processing procedures for batch O&M. For example, if an administrator selects a SoC board and all 20 containers on the board in the scheduling system's O&M interface, selects the "firmware update" O&M type, and confirms, the scheduling system generates a trigger command containing the O&M type, target hardware identifier, and container scope, and sends it to the gating module to trigger the start of the batch O&M task.

[0087] A pre-maintenance runtime status snapshot is a collection of real-time runtime states of all container instances on the hardware device, acquired and recorded by the gating module before the execution of batch maintenance tasks. Its purpose is to provide a baseline for container state recovery after maintenance, ensuring that the container state can be restored to its reasonable pre-maintenance state and avoiding container state chaos caused by maintenance operations. Upon receiving the batch maintenance task trigger command, the gating module immediately sends a status acquisition command to the hardware device. Upon receiving the command, the hardware device collects real-time runtime status data of all created containers, organizes it, and feeds it back to the gating module. After receiving the data, the gating module stores the status information of all containers in a preset format, forming a pre-maintenance runtime status snapshot, and stores it in the snapshot database of the scheduling system for easy parsing and retrieval after maintenance. For example, after receiving a batch maintenance trigger command, the gating module sends a status acquisition command to the SoC board, collects the status data of 20 containers on the board, organizes it, forms a pre-maintenance runtime status snapshot, and stores it in the snapshot database, providing a basis for subsequent state recovery. Container identifier, running status bit, and startup priority are components of the pre-operational state snapshot. Together, they constitute a complete description of the container's pre-operational state, providing accurate data support for post-operational state recovery. The container identifier is a unique identifier for each container instance, used to accurately locate a single container. It can be automatically assigned by the scheduling system when the container is created and stored in the container management database. The gating module retrieves it by querying the database and records it in the snapshot. The running status bit is a standardized code used to characterize the real-time running status of the container before maintenance. It uses fixed coding rules to distinguish between running, starting, and stopped states. After the hardware device collects the container status, it feeds back the corresponding status code to the gating module, which records it in the snapshot. The startup priority is a priority identifier pre-configured for each container, characterizing the importance of the container's business. It is consistent with the preset priority label mentioned above. The gating module can query the preset priority label of each container from the container management database and record it in the snapshot. For example, if a container's container identifier is "CTR-006" and it is in a running state before maintenance, the corresponding running status bit code is "01" and the startup priority is "high". These three pieces of information are recorded together in the running status snapshot before maintenance, clearly showing the container's state before maintenance.

[0088] The list of containers to be restored is a collection of all container instances that need to be restored after the batch operation and maintenance tasks are completed. It includes all containers created on the hardware device and is completely consistent with the container set before operation and maintenance. The startup priority of each container is the startup priority of each container before operation and maintenance, which is extracted from the snapshot by the gating module and is consistent with the startup priority recorded in the snapshot. It is used for subsequent startup attempts to be performed according to priority. After the batch operation and maintenance tasks are completed, the snapshot of the running status before operation and maintenance can be read from the snapshot database. Through the built-in snapshot parsing unit, the information of each container in the snapshot is parsed one by one, the container identifier and the corresponding startup priority are extracted, all container identifiers are organized into a list of containers to be restored, and the startup priority corresponding to each container is associated and stored in the data cache area to provide data support for subsequent startup attempts. For example, after the gating module parses the snapshot, it obtains a list of containers to be restored containing 20 container identifiers, of which 5 containers have a startup priority of "high", 10 have a priority of "medium" and 5 have a priority of "low". The gating module stores the list with priorities for subsequent startup operations.

[0089] The gating module monitors the execution progress of batch maintenance tasks in real time. When it detects that the hardware device has reported the completion of the batch maintenance task, it can immediately retrieve the corresponding pre-maintenance running status snapshot from the snapshot database. Through the built-in snapshot parsing unit, it parses the container identifier, running status bit, startup priority, and other information in the snapshot one by one, filters out all created container identifiers, and organizes them into a list of containers to be restored. At the same time, it extracts the startup priority corresponding to each container identifier, establishes the association between container identifier and startup priority, completes the acquisition of the list of containers to be restored and their corresponding priorities, and then enters the subsequent startup attempt process. For example, after the batch maintenance task of container firmware update on the SoC board is completed, the gating module detects the maintenance completion feedback, retrieves the previously stored pre-maintenance running status snapshot, parses it to obtain a list of containers to be restored containing 20 container identifiers, and at the same time, it extracts the startup priority of each container, identifying 5 high-priority containers, 10 medium-priority containers, and 5 low-priority containers, preparing for subsequent startup attempts.

[0090] The second container is a container instance selected by the gating module from the list of containers to be recovered, in descending order of startup priority, to perform a startup attempt. It belongs to the list of containers to be recovered, and the selection order is determined by startup priority; higher-priority containers are selected first as the second container to prioritize the recovery of core business containers, ensuring that core business operations are not affected by maintenance. The containers in the list of containers to be recovered can be sorted from highest to lowest startup priority, and containers are selected sequentially according to the sorting order, one container at a time as the second container, performing a startup attempt until the number of successfully started containers reaches a preset concurrent running threshold. The selection process is automatic and requires no manual intervention. For example, if the five high-priority containers in the list of containers to be recovered are sorted as "CTR-006", "CTR-007", "CTR-008", "CTR-009", and "CTR-010", the gating module will first select "CTR-006" as the second container to perform a startup attempt. After successful startup, "CTR-007" will be selected as the second container, and so on.

[0091] The gating module first sorts all containers in the list of containers to be restored according to their startup priority from highest to lowest, with high-priority containers at the top, medium-priority containers next, and low-priority containers at the bottom. Then, following the sorting order, the gating module sequentially selects each container as the second container, sends a startup permission command to the hardware device, and executes a startup attempt. After the hardware device performs the startup operation, it feeds back the startup result to the gating module, which records the number of containers that successfully started. If the number of successfully started containers does not reach the preset concurrent operation threshold, the module continues to select the next second container to attempt startup. If the number of successfully started containers reaches the preset concurrent operation threshold, the startup attempt is immediately stopped, and no further containers are selected. For example, if the preset concurrent operation threshold is 6, and the list of containers to be restored contains 5 high-priority containers, 10 medium-priority containers, and 5 low-priority containers, the gating module sorts them by priority and sequentially selects high-priority containers to attempt startup. After all 5 high-priority containers start successfully, the number of successfully started containers is 5, which does not reach the threshold of 6. The module then selects one medium-priority container as the second container to attempt startup. After this successful startup, the number of successfully started containers reaches 6, and the startup attempt is stopped, and no further containers are selected.

[0092] The third container is a container instance in the list of containers to be restored that was not selected as the second container for a startup attempt, or was selected as the second container but failed to start successfully. These containers belong to the list of containers to be restored because the number of successful startups has reached the preset concurrent running threshold or startup failures prevent restoration to the pre-maintenance running state, and a state reset is required. After stopping startup attempts, the list of containers to be restored can be compared with the list of successfully started containers to filter out the container instances that failed to start; these are the third containers. If a container was selected as the second container but failed to start, that container is also included in the third container category. For example, if the list of containers to be restored contains 20 containers, and 6 containers successfully started (5 high-priority and 1 medium-priority), the remaining 14 containers (9 medium-priority and 5 low-priority) were not selected for a startup attempt; these 14 containers are the third containers. If one of the high-priority containers fails to start, that container is also listed as a third container.

[0093] After identifying the third container, the gating module can generate a status reset command through its built-in status reset unit. This command clearly identifies all third containers and specifies their target status (stopped state). The status reset command is then sent to the hardware device via the transmission control protocol interface. Upon receiving the command, the hardware device resets the running status bit of each third container from its current state (which may be startup failure, not started, etc.) to the stopped state. After completing the reset, it sends the result back to the gating module. Upon receiving the feedback, the gating module synchronously updates the running status of the third containers in the container management database to ensure data consistency. For example, if 14 third containers are currently in the "not started" state, the gating module sends a status reset command. Upon receiving this command, the hardware device resets the running status bit of all 14 third containers to the stopped state, sends back a reset completion message, and the gating module synchronously updates the container management database, completing the status cleanup after batch maintenance.

[0094] For example, the administrator initiates a batch maintenance task for firmware updates on 20 containers on a SoC board through the scheduling system. The scheduling system generates a trigger command and sends it to the gating module. After receiving the command, the gating module sends a status acquisition command to the SoC board to collect the running status of all containers, generate a snapshot of the running status before maintenance, and store it. The snapshot contains the identifier, running status bit, and startup priority of each container. After the batch maintenance task for firmware updates is completed, the gating module parses the snapshot of the running status before maintenance to obtain a list of 20 containers to be restored and the startup priority of each container, of which 5 are high priority and 10 are medium priority. The system first has five high-priority containers and five low-priority containers. The gating module sorts the containers by startup priority from high to low and selects the second container to attempt startup in sequence. The preset concurrent running threshold is 6. After all five high-priority containers have started successfully, one medium-priority container is selected to start successfully. Once the number of successful startups reaches 6, the startup attempt stops. Subsequently, the gating module sends a status reset command to the SoC board for the 14 third containers in the list of containers to be restored that have not started successfully. This resets their running status to the stopped state and updates the container management database synchronously. This completes the container status restoration after batch maintenance, ensuring that core business containers are restored first while ensuring that the computing power of the hardware devices is not overloaded.

[0095] By implementing the above embodiments, a snapshot of the container's running status is recorded before batch operation and maintenance, and the container is restored to operation according to the startup priority after operation and maintenance. Furthermore, the startup of subsequent containers is restricted after the concurrent operation threshold is reached. This achieves state consistency control during the operation and maintenance process, thereby ensuring that critical containers are restored to operation first and avoiding concurrent overload problems during the restoration process. It can balance system stability and business continuity in complex operation and maintenance scenarios.

[0096] Furthermore, as an implementation of the foregoing method embodiments, this application also provides a container scheduling apparatus for implementing the foregoing method embodiments. This apparatus embodiment corresponds to the foregoing method embodiments. For ease of reading, this container scheduling apparatus embodiment will not repeat the details of the foregoing method embodiments one by one, but it should be understood that the apparatus in this application embodiment can correspondingly implement all the contents of the foregoing method embodiments. For example... Figure 2As shown, the container scheduling device 20 includes: a data acquisition unit 201, a container creation unit 202, and a container startup unit 203. The data acquisition unit 201 is used to acquire a preset concurrent operation threshold and a preset maximum instantiation threshold for the hardware device. The preset concurrent operation threshold is determined based on the physical concurrent processing capability of the hardware device, and the preset maximum instantiation threshold is determined based on the available storage space of the hardware device. The preset maximum instantiation threshold is greater than the preset concurrent operation threshold. The container creation unit 202 is used to, in response to a container creation request, determine whether to create a target container based on a first comparison result between the total number of currently created containers and the preset maximum instantiation threshold, and configure the target container to a stopped state after determining to create the target container. The container startup unit 203 is used to, in response to a container startup request, acquire the number of currently active containers on the hardware device, and determine whether to start the target container based on a second comparison result between the number of currently active containers and the preset concurrent operation threshold.

[0097] In some embodiments, the container creation unit 202 is further configured to obtain a pre-configured over-configuration flag; when the over-configuration flag indicates that the over-configuration mode is enabled, in response to the container creation request, obtain the total number of currently created containers; if the total number of currently created containers is less than a preset maximum instantiation threshold, determine to create a target container; based on the over-configuration flag, generate a storage policy enforcement instruction for the target container, and modify the storage type of the target container to a preset remote shared storage type through the storage policy enforcement instruction.

[0098] In some embodiments, the container creation unit 202 is further configured to obtain the post-creation behavior configuration item corresponding to the target container; when the over-configuration flag indicates that the over-configuration mode is enabled, the automatic startup attribute in the post-creation behavior configuration item is forcibly set to a disabled state; and the initialization script execution entry point of the target container is modified to a null operation so that the target container is unconditionally stopped after creation.

[0099] In some embodiments, the container creation unit 202 is further configured to send a status acquisition instruction to the hardware device through the gating module; receive real-time running data returned by the hardware device based on the status acquisition instruction, wherein the real-time running data includes container status identifiers; and obtain the number of currently active containers by counting the containers in the running state and the startup state in the real-time running data.

[0100] In some embodiments, the container startup unit 203 is further configured to: generate a startup permission instruction if the number of currently active containers is less than a preset concurrent operation threshold, and send the startup permission instruction to the hardware device to perform a startup operation; generate a startup interception instruction if the number of currently active containers is greater than or equal to the preset concurrent operation threshold, and determine the number to be released based on the difference between the number of currently active containers and the preset concurrent operation threshold; and generate and output a first prompt message based on the number to be released, the first prompt message being used to indicate the number of containers that need to be stopped.

[0101] In some embodiments, the container startup unit 203 is further configured to obtain the preset priority label and last active timestamp of each active container corresponding to the current number of active containers; based on the preset priority label and last active timestamp, filter out the target container set from each active container, and generate a recommended stop list for the target container set; and output a second prompt message containing the recommended stop list.

[0102] In some embodiments, the container startup unit 203 is further configured to update the number of currently active containers on the hardware device in response to a stop operation instruction for at least one first container in the recommended stop list; and after detecting that the updated number of currently active containers meets the preset startup conditions, to trigger the startup process for the target container according to a preset startup waiting queue.

[0103] In some embodiments, the container startup unit 203 is further configured to, in response to a trigger command for a batch operation and maintenance task of a hardware device, acquire and record a snapshot of the pre-operation and maintenance running state of each container on the hardware device, the snapshot including the container identifier, running state bit, and startup priority; after the batch operation and maintenance task is completed, parse the snapshot of the pre-operation and maintenance running state to obtain a list of containers to be restored and the startup priority of each container; in order of startup priority from high to low, sequentially select the second container from the list of containers to be restored to perform a startup attempt until the number of successfully started containers reaches a preset concurrent operation threshold; for the third container in the list of containers to be restored that has not been successfully started, reset the running state bit of the third container to the stopped state.

[0104] This application also provides a computer-readable storage medium storing computer-executable instructions or computer programs that, when executed by a processor, will cause the processor to perform any step of the container scheduling method provided in this application.

[0105] In some embodiments, the computer-readable storage medium may be a random access memory (RAM), a read-only memory (ROM), flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); or it may be a variety of devices that include one or any combination of the above-mentioned memories.

[0106] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0107] In some embodiments, computer-executable instructions may, but do not necessarily, correspond to files in a file system, and may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0108] In some embodiments, computer-executable instructions may be deployed to execute on an electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0109] like Figure 3 As shown, this application also provides an electronic device 30, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, it implements any step of the container scheduling method described above.

[0110] This application also provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer program or computer-executable instructions from the computer-readable storage medium and executes the computer program or computer-executable instructions, causing the electronic device to perform any step of the container scheduling method described above.

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

Claims

1. A container scheduling method, characterized in that, Applied to hardware devices, the container scheduling method includes: Obtain a preset concurrent operation threshold and a preset maximum instantiation threshold for the hardware device, wherein the preset concurrent operation threshold is determined based on the physical concurrent processing capability of the hardware device, the preset maximum instantiation threshold is determined based on the available storage space of the hardware device, and the preset maximum instantiation threshold is greater than the preset concurrent operation threshold. In response to a container creation request, based on a first comparison result between the total number of currently created containers and the preset maximum instantiation threshold, it is determined whether to create the target container, and after determining to create the target container, the target container is configured to a stopped state; In response to a container startup request, the number of currently active containers on the hardware device is obtained, and based on a second comparison result between the number of currently active containers and the preset concurrent running threshold, it is determined whether to start the target container.

2. The container scheduling method according to claim 1, characterized in that, In response to a container creation request, determining whether to create the target container based on a first comparison result between the total number of currently created containers and the preset maximum instantiation threshold includes: Retrieve the pre-configured over-configuration flag; When the over-configuration flag indicates that over-configuration mode is enabled, in response to the container creation request, obtain the total number of containers that have been created. If the total number of currently created containers is less than the preset maximum instantiation threshold, then the target container is determined to be created. Based on the over-configuration flag, a storage policy enforcement instruction is generated for the target container, and the storage type of the target container is modified to a preset remote shared storage type through the storage policy enforcement instruction.

3. The container scheduling method according to claim 2, characterized in that, The step of configuring the target container to a stopped state includes: Retrieve the post-creation behavior configuration items corresponding to the target container; When the over-configuration flag indicates that over-configuration mode is enabled, the automatic power-on attribute in the post-creation behavior configuration item will be forcibly set to disabled. Modify the entry point of the initialization script of the target container to an empty operation so that the target container is unconditionally in the stopped state after creation.

4. The container scheduling method according to claim 1, characterized in that, The step of obtaining the number of currently active containers on the computing-limited hardware includes: The gating module sends a status acquisition command to the hardware device. Receive real-time operating data returned by the hardware device based on the status acquisition instruction, wherein the real-time operating data includes a container status identifier; The number of currently active containers is obtained by counting the containers in the running and startup states in the real-time running data.

5. The container scheduling method according to claim 4, characterized in that, The step of determining whether to start the target container based on the second comparison result between the current number of active containers and the preset concurrent operation threshold includes: If the number of currently active containers is less than the preset concurrent running threshold, a startup permission instruction is generated and sent to the hardware device to perform the startup operation; If the number of currently active containers is greater than or equal to the preset concurrent operation threshold, a start interception command is generated, and the number to be released is determined based on the difference between the number of currently active containers and the preset concurrent operation threshold. Based on the quantity to be released, a first prompt message is generated and output, which indicates the number of containers that need to be stopped.

6. The container scheduling method according to claim 5, characterized in that, After generating the startup interception instruction, the container scheduling method further includes: Obtain the preset priority tag and last active timestamp of each active container corresponding to the current number of active containers; Based on the preset priority tags and the last active timestamp, a target container set is selected from each active container, and a recommended stop list is generated for the target container set. The output includes a second prompt message containing the recommended stop list.

7. The container scheduling method according to claim 6, characterized in that, After outputting the second prompt message, the following is also included: In response to a stop operation command for at least one first container in the recommended stop list, update the current number of active containers on the hardware device; After detecting that the updated number of currently active containers meets the preset startup conditions, the startup process for the target container is triggered according to the preset startup waiting queue.

8. The container scheduling method according to claim 1, characterized in that, The container scheduling method further includes: In response to a trigger command for a batch maintenance task of the hardware device, a snapshot of the pre-maintenance running status of each container on the hardware device is acquired and recorded. The pre-maintenance running status snapshot includes container identifier, running status bit and startup priority. After the batch operation and maintenance tasks are completed, the snapshot of the running status before operation and maintenance is parsed to obtain the list of containers to be restored and the startup priority of each container; According to the order of startup priority from high to low, the second container is selected from the list of containers to be restored and the startup attempt is performed in turn until the number of containers that have been successfully started reaches the preset concurrent running threshold. For the third container in the list of containers to be restored that failed to start, the running status bit of the third container is reset to the stopped state.

9. A container scheduling device, characterized in that, The container scheduling device, applied to hardware devices, includes: A data acquisition unit is used to acquire a preset concurrent operation threshold and a preset maximum instantiation threshold for the hardware device, wherein the preset concurrent operation threshold is determined based on the physical concurrent processing capability of the hardware device, the preset maximum instantiation threshold is determined based on the available storage space of the hardware device, and the preset maximum instantiation threshold is greater than the preset concurrent operation threshold. The container creation unit is used to respond to a container creation request, determine whether to create a target container based on a first comparison result between the total number of currently created containers and the preset maximum instantiation threshold, and configure the target container to a stopped state after determining to create the target container; The container startup unit is used to respond to a container startup request, obtain the number of currently active containers on the hardware device, and determine whether to start the target container based on a second comparison result between the number of currently active containers and the preset concurrent running threshold.

10. An electronic device, comprising: A memory and a processor, characterized in that the processor, when executing a computer program stored in the memory, implements the steps of the container scheduling method as described in any one of claims 1 to 8.

Images