Real-time task scheduling method and device based on Docker container

Abstract

The invention provides a real-time task scheduling method and device based on a Docker container, and relates to the technical field of computers.The method comprises the steps that a CPU core of a target server is divided into special task core pools in advance; docker internal events are continuously monitored, the business priority and the container condition of each container are analyzed and obtained in real time, and according to the business priority and the container condition of each container, a task core pool which most meets the container resource requirement is selected and associated for each container from the core resource pool based on a dynamic container scheduling mapping relation; in the container operation process, the state of the target server is continuously detected, the processing priority of the tasks in the container is dynamically adjusted, and it is ensured that the high-priority tasks can be preferentially processed in the associated task core pool of the container when network congestion or delay fluctuation occurs. According to the invention, the response speed and stability of the server can be improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a real-time task scheduling method and apparatus based on Docker containers. Background Technology

[0002] Unlike virtual machines, Docker containers do not have independent operating systems. Containers achieve process-level isolation only through namespaces and cgroups. Because containers can only access resources, files, devices, configurations, and states limited to their current namespace, they lack the process management capabilities of an operating system and are unaware of other processes on the host machine. Typically, the main process within a container (the process with PID=1) is the application itself, and other processes are its child processes. If the main process is functioning correctly, the Docker status is "Running." Therefore, running multiple processes within a container is discouraged; instead, it's encouraged to decouple applications into multiple containers, each with a single function. This allows for easier scaling and reuse of containers. However, some applications consist of multiple tightly coupled processes that are difficult to split into different containers, or the splitting process carries significant risks. Therefore, there is a real need to run multiple processes within a single container. This scenario is often achieved through a managed proxy main process model.

[0003] Chinese patent CN116107715B discloses a method and task scheduler for running Docker container tasks. The method includes: a task scheduler running on a management node, with the scheduler service running as the root superuser. The method includes the following steps: the task scheduler receives a task submission command related to the Docker container; the task scheduler authenticates the user within the Docker container; if the user authentication is successful, the task scheduler schedules the Docker container task corresponding to the task submission command to the task execution management service of the computing node, and the task execution management service runs the Docker container task in a restricted manner. However, in the deployment of virtualized Docker technology, the above solution requires sequential execution of each application process through time-slice polling. The scheduling strategy prioritizes fairness over real-time performance, resulting in insufficient server response speed and stability, making it difficult to guarantee service quality. Service quality refers to the ability to guarantee the allocation of computing resources (such as CPU cores), scheduling priority, and operational stability of containers or tasks, ensuring that critical applications obtain the necessary resources and response performance.

[0004] Therefore, overcoming the shortcomings of the existing technology is an urgent problem to be solved in this technical field. Summary of the Invention

[0005] To address the aforementioned deficiencies or improvement needs of existing technologies, this invention proposes a real-time task scheduling method and apparatus based on Docker containers. By pre-partitioning the CPU cores on the target server and constructing a dynamic container scheduling mapping relationship, the task processing priority of Docker containers is dynamically adjusted to improve the server's response speed and stability.

[0006] This invention provides a real-time task scheduling method based on Docker containers, the method comprising: The CPU cores of the target server are pre-divided into dedicated task core pools, wherein the task core pools are functionally isolated from each other, and the number of CPU cores in each task core pool can be dynamically adjusted according to the system load. Continuously monitor Docker internal events, parse and obtain the business priority and container status of each container in real time, and select and associate the task core pool that best meets the container resource requirements from the core resource pool based on the dynamic container scheduling mapping relationship. During container operation, the status of the target server is continuously monitored, and the processing priority of tasks within the container is dynamically adjusted to ensure that high-priority tasks are processed first in the task core pool associated with the container when network congestion or latency fluctuations occur.

[0007] Preferably, the step of pre-dividing the CPU cores of the target server into dedicated task core pools, wherein the task core pools are functionally isolated from each other, and the number of CPU cores in each task core pool can be dynamically adjusted according to the system load, including: Obtain the number, model, and current usage of all CPU cores in the target server, and determine the number of CPU cores required for real-time tasks and ordinary tasks based on the application type and real-time task requirements. Based on the task's real-time requirements, task level, and expected load, combined with the number of CPU cores required for real-time and ordinary tasks, the partition ratio is obtained and recorded in the preset partitioning strategy. The preset partitioning strategy is then embedded into the system initialization and Docker container startup scripts. The system periodically polls the partition ratio, workload, and other information of the real-time task core pool and the ordinary task core pool to adjust the number of CPU cores in the target server. The adjusted results are then written into the preset partitioning strategy and stored.

[0008] Preferably, the container information includes a unique identifier, container type, and task attributes. The method further includes: Parse the internal events generated in the Docker environment to obtain the unique identifier, container type, task attributes, and business priority of the Docker container corresponding to the internal event; The container type, task attributes, and business priority of each Docker container are mapped to preset scheduling rules to determine the scheduling priority value corresponding to each Docker container and generate container scheduling parameters. The preset scheduling rules include a first mapping table that converts container type and task attributes into basic scheduling weights and a second mapping table that maps business priorities to predetermined scheduling priorities. Based on the container scheduling parameters, determine the task core pool that best meets the resource requirements of each Docker container, and bind each container to the corresponding task core pool.

[0009] Preferably, the method includes: For the i-th task in a container, the migration compensation value of the i-th task at time t is calculated using a dynamic delay function; Based on the migration compensation value and the basic priority of the i-th task, the processing priority of the i-th task is obtained through the task level adjustment function, so as to schedule and execute the processing priorities of each task in the container from high to low.

[0010] Preferably, the expression for the task level control function is: ; ; ; in, n This indicates the total number of tasks participating in the scheduling. C i Indicates the first i The execution time of each task T i Indicates the first i The cycle of each task, ω i ( t ) indicates at time t Time i Dynamic weighting factors for each task m Δ represents the total number of task migrations performed. j ( t ) indicates at time t Time j The additional latency caused by each task migration. U crit This represents the critical utilization threshold. ω 0 indicates an initial fixed weight factor. L i( t ) indicates at time t Time i Migration compensation function for each task, f () represents the dynamic function of the task characteristics. p i ( t ) represents the task level control function. p base Indicates the basic priority of the task. α Represents the periodic dynamic weighting factor. D i Indicates the first i The deadline for each task. β This represents the time weighting factor for the difference. γ This represents the migration compensation factor.

[0011] Preferably, the migration compensation value for the i-th task is calculated using a migration compensation function, the expression of which is: ; in, Li represents the migration compensation value for the i-th task, L0 represents the basic compensation factor under ideal network conditions, Delay(t) represents the dynamic delay function, Delayref represents the preset reference delay, compensation begins when Delay(t) exceeds this value, and τ represents the adjustment coefficient, reflecting the degree of influence of the excess delay on the migration compensation function Li(t).

[0012] Preferably, the expression for the dynamic delay function is: ; ; ; Where Delay(t) represents the dynamic delay function, B(t) represents the size of the bucket in the token bucket model at time t, r(t) represents the token generation rate at time t, B0 represents the size of the base bucket in the token bucket model, k represents the adjustment coefficient, Q(t) represents the queue length at time t, Qref represents the reference queue length, r0 represents the base token generation rate, g() represents the load queue adjustment function, TL(t) represents the network traffic load at time t, η(t) represents the proportion of network resources actually allocated at time t, η0 represents the reference proportion of network resource allocation, μ represents the deviation adjustment coefficient, and λ represents the allocation adjustment coefficient.

[0013] Preferably, parsing internal events generated in the Docker environment to obtain the unique identifier, container type, task attributes, and business priority of the Docker container corresponding to the internal event further includes: When a Docker container is created, resource limits for CPU cores, memory, and disk I / O can be specified through parameterized configuration. Record the running status, port binding relationships, and resource usage of Docker containers, and store the information in a centralized management database; When a Docker container is destroyed, the port bindings are automatically released, and the records in the management database are updated synchronously.

[0014] A second aspect of this application provides an electronic device including a processor, a memory, a user interface, and a network interface, wherein the memory is used to store instructions, the user interface and the network interface are used to communicate with other devices, and the processor is used to execute the instructions stored in the memory.

[0015] A third aspect of this application provides a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the steps of a real-time task scheduling method based on Docker containers.

[0016] The present invention provides a real-time task scheduling method and apparatus based on Docker containers, which has the following advantages over the prior art: By pre-partitioning the CPU cores on the target server, resource isolation between different task types is achieved, ensuring that latency-sensitive real-time tasks can obtain dedicated cores, effectively reducing task response time and improving real-time response quality. Furthermore, by utilizing real-time monitoring of Docker internal events, automatic matching between containers and partitioned resources is achieved, generating scheduling parameters for each container, enabling the target server to dynamically adjust resource allocation according to business priorities and task characteristics. At the same time, by utilizing network latency data and task level adjustment functions, the task processing priority of Docker containers is dynamically adjusted, ensuring that high-priority tasks can be processed as quickly as possible when there is network congestion or latency fluctuations. This allows the target server to efficiently manage and schedule real-time and ordinary tasks in microservice containerized deployment, optimize resource utilization, reduce latency, improve server response speed and stability, and ensure service quality through dynamic network traffic control.

[0017] Furthermore, by monitoring internal events generated in the Docker environment in real time, the unique identifier, type, task attributes, and task level of each container can be accurately captured. Combined with preset rules, containers are mapped to corresponding scheduling weights and priorities, achieving more reasonable allocation of CPU core resources and thus improving the overall system resource utilization. By dynamically adjusting container scheduling parameters with the help of two mapping tables, the mapping relationship between containers and CPU cores can be automatically updated when the task priorities of different containers change, ensuring load balancing and efficient system operation. By refining container scheduling parameters, tasks can be pushed to the appropriate CPU cores for execution more quickly, thereby reducing container waiting time, improving task processing efficiency, significantly reducing scheduling latency, and improving system response speed. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0019] Figure 1 This is a flowchart illustrating a real-time task scheduling method based on Docker containers provided in an embodiment of the present invention. Figure 2 This is a flowchart illustrating a partitioning method provided in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the implementation method of step 102 provided in an embodiment of the present invention; Figure 4 This is a flowchart illustrating the method for adjusting task processing priority provided in an embodiment of the present invention; Figure 5 This is a block diagram of a real-time task scheduling system based on Docker containers provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of a real-time task scheduling device based on Docker containers, provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0021] Unless the context otherwise requires, throughout the specification and claims, the term "comprising" is interpreted as openly inclusive, meaning "including, but not limited to." In the description of the specification, terms such as "one embodiment," "some embodiments," "exemplary embodiment," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with that embodiment or example is included in at least one embodiment or example of this disclosure. The illustrative representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics mentioned may be included in any suitable manner in any one or more embodiments or examples; that is, although they may be incorporated into embodiments or examples using the above terms for reasons such as order and position, it does not limit them to be incorporated in combination by a single embodiment or example.

[0022] In the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more. Furthermore, for example, the description may use the prefix "A" or "B" to describe the same type of nouns as two independent entities. In this case, the corresponding features defined with "A" and "B" are used only to distinguish between similar entities and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features.

[0023] In the description of this invention, the expression “A and / or B” (where A and B are used to formally represent specific features) will be used. The corresponding expression includes the following three combinations: only A, only B, and a combination of A and B.

[0024] As used in this invention, “about,” “approximately,” or “approximately” includes the stated value and the average value within an acceptable range of deviation from a particular value, wherein the acceptable range of deviation is determined by a person skilled in the art taking into account the measurement under discussion and the error associated with the measurement of the particular quantity (i.e., the limitations of the measurement system).

[0025] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0026] Example 1: The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0027] like Figure 1 As shown in the figure, this embodiment provides a real-time task scheduling method based on Docker containers, which specifically includes the following steps: Step 101: The CPU cores of the target server are pre-divided into dedicated task core pools, wherein the task core pools are functionally isolated from each other, and the number of CPU cores in each task core pool can be dynamically adjusted according to the system load.

[0028] In one embodiment, the Docker engine is installed on the target server, ensuring its version meets the hardware and software requirements for running the Linux operating system. Since Docker containers are a standard, lightweight runtime environment for running applications and all their dependencies, necessary kernel modules (such as nftables, seccomp, etc.) are enabled when configuring the Docker runtime environment. nftables is primarily used for network traffic management, security policy enforcement, and the isolation and control of container networks; seccomp is a security mechanism provided by the Linux kernel to restrict the system calls that processes can execute. In Docker, seccomp is used to enhance container security by limiting the system calls that processes within the container can use, thereby reducing the potential attack surface.

[0029] In one embodiment, the CPU cores in the target server are partitioned into a real-time task core pool and a normal task core pool. The CPU cores in the real-time task core pool execute only real-time tasks, while the CPU cores in the normal task core pool execute only normal tasks. Since real-time tasks are typically very latency-sensitive, requiring a sufficient number of cores to ensure low latency and high response speed, interrupt and scheduling latency need to be strictly controlled. For example, a real-time task may require binding to one or two cores and not being preempted by other processes; that is, the real-time task needs to exclusively occupy a CPU core until execution is complete. Normal tasks, on the other hand, typically have more relaxed latency requirements, allowing them to share core resources under certain load fluctuations. Normal tasks can use CPU cores through polling. Based on the differences between real-time and normal tasks, partitioning CPU cores into real-time task core pools and normal task core pools allows for the allocation of dedicated CPU cores for latency-sensitive real-time tasks. Compared to methods where real-time and normal tasks share CPU cores through polling, this partitioning method effectively reduces task response time and improves real-time response performance. For specific partitioning methods, please refer to [link to relevant documentation]. Figure 2 A flowchart.

[0030] Step 102: Continuously monitor Docker internal events, parse and obtain the business priority and container status of each container in real time, and select and associate the task core pool that best meets the container resource requirements from the core resource pool based on the dynamic container scheduling mapping relationship.

[0031] In one embodiment, a pre-built dynamic container scheduling map is used to locate the unique identifier (or container ID) of the corresponding container and the set of CPU cores (e.g., "0,1") allocated to that container. The set of CPU cores either belongs entirely to the real-time task core pool or entirely to the normal task core pool. The dynamic container scheduling map can be stored in memory, a database, or a configuration file and updated in real-time based on system load and scheduling policies. The Docker command or API (such as `docker inspect`) is used to obtain the container's main process PID and all processes within the container that need to be bound to CPU cores. In some application scenarios, it may be necessary to parse the PIDs of multiple processes within the container or directly manage the container's cgroups. If the container has already specified a `cpuset` configuration at startup, the existing configuration can also be dynamically adjusted or verified at runtime.

[0032] In one embodiment, the CPU affinity of a target process is set to a pre-allocated set of CPU cores using scheduling interfaces provided by the Linux kernel (such as the `sched_setaffinity` system call) or command-line tools (such as `taskset`). This can be implemented by writing scripts or service programs to call the corresponding system calls; for example, for a single process, calling `sched_setaffinity(pid, cpuset)`; or using the `taskset` command, such as `taskset -pc 0,1`. <pid>This ensures that the process runs only on a specified core. At the container level, this is often used in conjunction with the cpuset cgroup mechanism, which places container processes into specific cpuset cgroups and binds those cgroups to a specified set of CPU cores to ensure resource isolation and scheduling stability.

[0033] Step 103: During container operation, continuously monitor the status of the target server and dynamically adjust the processing priority of tasks within the container to ensure that high-priority tasks can be processed first in the task core pool associated with the container when network congestion or latency fluctuations occur.

[0034] In one embodiment, the selection and binding in step 102 can map containers to corresponding task core pools for computation. However, in the event of network congestion or latency fluctuations, the lack of a dynamic scheduling mechanism may prevent high-priority tasks from obtaining the necessary computing power in a timely manner, thus affecting service quality and response determinism. This embodiment dynamically adjusts the processing priority of tasks within containers so that high-priority tasks can be processed first in the event of network congestion or latency fluctuations. This enables the target server to efficiently manage and schedule real-time and ordinary tasks in a microservice containerized deployment, optimizing resource utilization, reducing latency, and improving server response speed and stability.

[0035] In this embodiment, by pre-partitioning the CPU cores on the target server, resource isolation between different task types is achieved. This ensures that latency-sensitive real-time tasks can obtain dedicated cores, effectively reducing task response time and improving real-time response quality. Furthermore, by utilizing real-time monitoring of Docker internal events, a dynamic container scheduling mapping relationship is constructed to achieve automatic matching between containers and partitioned resources. Scheduling parameters are generated for each container, enabling the target server to dynamically adjust resource allocation based on business priorities and task characteristics. Simultaneously, network latency data and task level adjustment functions are used to dynamically adjust the task processing priority of Docker containers, ensuring that high-priority tasks can be processed as quickly as possible during network congestion or latency fluctuations. This allows the target server to efficiently manage and schedule real-time and ordinary tasks in microservice containerized deployment, optimize resource utilization, reduce latency, and improve server response speed and stability. At the same time, dynamic network traffic control ensures service quality.

[0036] like Figure 2 As shown, this embodiment provides a partitioning method, which specifically includes the following steps: Step 201: Obtain the number, model, and current usage of all CPU cores in the target server, and determine the number of CPU cores required for real-time tasks and ordinary tasks based on the application type and real-time task requirements.

[0037] In one embodiment, the Linux command "lscpu" can be used to output the CPU architecture information of the entire system, including the total number of cores, threads, CPU model, and architecture; or the ` / proc / cpuinfo` file can be viewed, which records detailed information about each core, including the "processor" number and "model name". Monitoring tools (such as `top`, `htop`, `mpstat`, or `sar`) can be used to understand the real-time load and utilization of each CPU core. For example, executing the command `mpstat -PALL11` can display the utilization of all cores, and `top` / `htop` can also visually display the current load of each core.

[0038] In one embodiment, the CPU response time requirements for real-time tasks can be determined based on the application scenario. Generally, if there are latency-sensitive or time-sensitive tasks in the system, some cores should be reserved specifically for real-time tasks. Based on the total number of cores and the current CPU load, the expected load can be assessed. If the target server has a total of N cores, a certain proportion can be allocated according to the needs of real-time tasks (e.g., reserving 20%-30% as real-time task cores), with the remaining cores used for ordinary tasks. Furthermore, a reasonable allocation strategy can be determined by referring to the system's peak workload and task criticality, using performance testing tools and stress test results. For example, in an 8-core system, if real-time tasks have high stability requirements, 2-3 cores can be reserved as real-time task cores, while the remaining cores are used for ordinary business operations.

[0039] Step 202: Based on the task's real-time requirements, task level, and expected load, combined with the number of CPU cores required for real-time tasks and ordinary tasks, obtain the partition ratio and record it in the preset partitioning strategy. Embed the preset partitioning strategy into the system initialization and Docker container startup scripts.

[0040] In one embodiment, based on step 201, the total number, model, architecture, and thread information of all CPU cores in the system are obtained, and the number of physical cores and logical cores are recorded to determine whether hyper-threading technology is supported. Using tools such as mpstat, top, htop, or sar, real-time load, utilization, and idle status of each core are collected, along with historical usage data within a certain time range, to assess resource consumption during different business periods (such as peak and off-peak times). Based on the real-time requirements of each task, such as deadlines, response latency, and continuity requirements, key indicators (such as maximum allowable latency and response jitter range) are recorded for real-time tasks to determine the task level and corresponding resource sensitivity of each task. Existing applications are classified to identify which tasks are real-time and which are ordinary tasks. The daily and peak load of each task is analyzed, the load characteristics of different tasks under various load scenarios are estimated, and performance test data or historical running logs are collected to understand the system's performance under different load conditions. The partition ratio is determined by combining the CPU cores required for real-time and ordinary tasks in step 201. For mixed scenarios, the priority, workload requirements, and fault tolerance of real-time and ordinary tasks are compared. Assess whether real-time tasks will quickly reach resource bottlenecks under different load conditions, and determine whether more cores need to be reserved to avoid mutual interference. Based on performance testing or simulation, analyze the potential latency and scheduling conflicts that may occur when the same core is allocated to two types of tasks at the same time.

[0041] Furthermore, considering the total number of cores and estimated task usage, for example, in an 8-core system, assuming data collection reveals that real-time tasks are critical, and historical data shows that peak CPU utilization for real-time tasks can reach 50%, it's advisable to reserve 2-3 cores as dedicated resources for real-time tasks. This ensures that real-time task cores will not experience increased response latency due to contention by ordinary tasks at any time. Based on the task's real-time requirements, initially determine the proportion of the real-time task core pool (e.g., 30%-40%), with the remaining cores allocated to the ordinary task core pool. In low-load scenarios, a real-time task might theoretically require only one core, but to handle potential business surges, a higher redundancy value can be considered. After establishing the initial proportion, it's recommended to establish a dynamic monitoring and feedback mechanism to monitor the latency and load fluctuations of real-time tasks and the response performance of ordinary tasks during runtime, adjusting the partitioning ratio accordingly.

[0042] In one embodiment, the predefined partition configuration file includes one or more of the following: total number of CPU cores, CPU core identifier, partition type identifier, number of reserved cores, limiting parameters corresponding to the real-time task core pool, and limiting parameters corresponding to the normal task core pool. Additionally, a preset partitioning strategy is written into the predefined partition configuration file, and the predefined partition configuration file is embedded in the system initialization and Docker container startup scripts. When the partitioning strategy changes subsequently, the corresponding content of the predefined partition configuration file will also change.

[0043] Step 203: Periodically poll to obtain the partition ratio, workload, and other information of the real-time task core pool and the ordinary task core pool. Adjust the partitions of the CPU cores in the target server, write the adjusted results into the preset partitioning strategy, and store them.

[0044] In one embodiment, the execution status (work share, workload, etc.) of CPUs in the task core pool is obtained through polling. Based on the execution status, it is determined whether partitioning adjustments are needed. That is, CPU cores from one task core pool are moved out and bound to another CPU core pool to maximize the utilization of resources from both task core pools. Since the container is already bound to the corresponding task core pool, the number of CPU cores in each task core pool can be dynamically and adaptively adjusted according to the real-time load of CPUs in the task core pool. This allows for more efficient utilization of CPU core resources, ensuring that applications in the container have sufficient computing power under high load and releasing redundant resources for other tasks under low load, thereby improving overall system performance and resource utilization.

[0045] In one embodiment, a dynamic container scheduling mapping is constructed based on the type, task attributes, and task level of the Docker containers. Specifically, command-line tools, such as executing the "docker events" command, can be used to output all event information in real time, or events can be subscribed to through the Docker API's / events interface, or events can be listened to using a long-lived socket connection in a programming environment (such as Python or Go). Filtering conditions can also be set, such as for "container" type events. For example, when using the REST API, the filter parameter can be specified to filter key events such as "create," "start," and "die," reducing irrelevant data.

[0046] The event data (usually in JSON format) of the monitored internal events is parsed to extract key information related to container scheduling. This includes: "Type": confirming the event type (e.g., container); "Action": the operation name, such as create, start, stop, die, etc.; "ID" in "Actor": the container identifier; "Attributes" in "Actor": potentially containing custom metadata such as image name, container labels, and environment variables; the "Action" field helps determine the nature of the event. If it's a container creation or startup event, further detailed container information is needed; if it's a stop or destruction event, the container can be unregistered in the scheduling map. The parsed event timestamp ("Time" field) is used to determine the timing and urgency of the event. Filtering rules are used to discard irrelevant events, ensuring the scheduling system only processes events related to task attributes and levels.

[0047] In one embodiment, if the event data contains sufficient metadata, it can be used directly. If the data does not define the container type or task attributes in detail, after receiving the event, further container details can be obtained through the Docker API's "inspect" interface; that is, by calling the Docker API or using the "docker inspect <container ID>" command to obtain container details. Parsing the returned JSON data yields the following: custom tags are typically used to indicate the task type (e.g., real-time task, batch task, etc.) and task level (high, medium, low); environment variables can be used to pass more granular task attribute information, such as predefined load metrics, service identifiers, or other scheduling parameters; HostConfig parameters (e.g., resource limits, bound CPU cores, etc.) reflect the container's current environment configuration, classifying the container as a real-time task or a normal task based on the scheduling requirements defined in the tags or environment variables.

[0048] In one embodiment, a scheduling mapping table or data structure, such as a dictionary or database table, is established, where the key is the container ID and the value is the scheduling parameter setting (such as the bound CPU core number, priority identifier, task level).

[0049] In one embodiment, when a Docker container is created, the resource limits for CPU cores, memory, and disk I / O of the Docker container are specified by parameterized configuration; the running status, port binding relationships, and resource usage of the Docker container are recorded and the information is stored in a centralized management database; when the Docker container is destroyed, the port binding relationships are automatically released and the records in the management database are updated synchronously.

[0050] like Figure 3 As shown, this embodiment provides a specific implementation method for step 102, which specifically includes the following steps: Step 301: Parse the internal events generated in the Docker environment to obtain the unique identifier, container type, task attributes, and business priority of the Docker container corresponding to the internal event.

[0051] In one embodiment, a long-term connection is established using Docker's event interface (e.g., by running the "docker events" command or using the / events endpoint of the Docker API) to subscribe in real-time to various internal events occurring in the Docker daemon. Filtering rules are set (e.g., focusing only on container-type events) to reduce irrelevant information. Filtering conditions can specify monitoring of key events such as "create," "start," and "update" to ensure that all events related to container state changes are captured.

[0052] If the event data contains sufficient metadata, it can be used directly. If the data does not define the container type or task attributes in detail, further detailed container information can be obtained through the Docker API's "inspect" interface after receiving the event. Use the "docker inspect <container ID>" command or API call to obtain complete JSON information, and further parse the tags or environment variables to extract the container type (e.g., "real-time", "batch"), task attributes (e.g., service name, workload type), and task level (high, medium, low).

[0053] Step 302: Map the container type, task attributes, and business priority of each Docker container to the preset scheduling rules, determine the scheduling priority value corresponding to each Docker container, and generate container scheduling parameters. The preset scheduling rules include a first mapping table that converts container type and task attributes into basic scheduling weights and a second mapping table that maps business priorities to predetermined scheduling priorities.

[0054] In one embodiment, the first mapping table defines the conversion relationship between container type and task attribute to basic scheduling weights. For example, the following rule is pre-configured: if the container type is "real-time" and the task attribute is "speech processing", the basic weight can be set to 80; if the container type is "batch" and the task attribute is "data analysis", the basic weight can be set to 40. The second mapping table is used to map a correction or supplementary value to a scheduling priority based on the task level (e.g., high, medium, low). For example, if the task level is "high", the priority is increased by 20 points; if the task level is "low", the priority is decreased by 10 points.

[0055] Based on the unique identifier, container type, task attributes, and task level of each container, the basic scheduling weight corresponding to the container type and task attribute is read from the first mapping table, and the priority supplementary value corresponding to the task level is found from the second mapping table. These two values ​​are then combined to generate the final scheduling priority value. For example, a simple addition method can be used to obtain the scheduling priority as the sum of the basic scheduling weight and the supplementary value.

[0056] Based on the calculated scheduling priority value, a specific set of scheduling parameters is matched for the container, including but not limited to: priority value (directly used for subsequent scheduling decisions), resource binding suggestions such as recommended CPU core pool allocation and memory quota, and possible scheduling policy identifiers (e.g., a high-priority scheduler for real-time tasks and a low-priority scheduler for ordinary tasks). These parameters can be stored in a mapping table in a structured data format or passed to Docker's startup script and resource management system in real time, thereby achieving dynamic container scheduling mapping. When a new container event occurs, the system calculates the current container's scheduling priority according to the above steps and then updates this information to the global scheduling mapping table. During container runtime, the scheduling system can periodically or when critical events are triggered to re-evaluate the scheduling priority to ensure it matches the current task load, latency requirements, and resource status.

[0057] Step 303: Based on the container scheduling parameters, determine the task core pool that best meets the resource requirements of each Docker container, and bind each container to the corresponding task core pool.

[0058] In one embodiment, by monitoring internal events generated in the Docker environment in real time, the unique identifier, type, task attributes, and task level of each container can be accurately captured. Combined with preset rules, containers are mapped to corresponding scheduling weights and priorities, achieving more reasonable allocation of CPU core resources and thus improving the overall system resource utilization. By dynamically adjusting container scheduling parameters with the help of two mapping tables, the mapping relationship between containers and CPU cores can be automatically updated when the task priorities of different containers change, ensuring load balancing and efficient system operation. By refining container scheduling parameters, tasks can be pushed to the appropriate CPU cores for execution more quickly, thereby reducing container waiting time, improving task processing efficiency, significantly reducing scheduling latency, and improving system response speed.

[0059] like Figure 4 As shown in the figure, this embodiment provides a method for adjusting task processing priority, which specifically includes the following steps: Step 401: For the i-th task in a container, calculate the migration compensation value of the i-th task at time t using the dynamic delay function.

[0060] In one embodiment, the migration compensation value for the i-th task is calculated using a migration compensation function, the expression of which is: ; in, This represents the migration compensation value for the i-th task. L 0 represents the basic compensation factor under ideal network conditions. Delay ( t ) represents the dynamic delay function. Delay ref This indicates the preset reference delay, when Delay ( t Compensation begins when this value is exceeded. τ This represents the control coefficient, reflecting the effect of the delay excess on the migration compensation function. L i ( t The extent of its impact.

[0061] It can also be written in piecewise function form: if Delay ( t )≤ Delay ref ,but L i ( t )= L 0.

[0062] if Delay ( t )> Delay ref ,but L i ( t )= L 0+ τ ·( Delay ( t )- Delay ref ).

[0063] When network transmission latency exceeds expectations, the migration compensation function L i ( t The value of the compensation factor will increase, and its role in the calculation of the overall priority of tasks will be enhanced, thereby enabling task scheduling to adapt to changes in network conditions.

[0064] In one embodiment, the expression for the dynamic delay function is:

[0065]

[0066]

[0067] in, Delay ( t ) represents the dynamic delay function. B ( t ) indicates at time t The size of the bucket in the token bucket model. r ( t ) indicates at time t The rate at which tokens are generated. B 0 represents the size of the base bucket in the token bucket model. k This represents the adjustment coefficient. Q ( t ) indicates at time t The queue length at that time, Q ref Indicates the reference queue length. r 0 represents the base token generation rate. g () represents the load queue adjustment function. TL ( t ) indicates at time t Network traffic load at that time η ( t The ) represents the proportion of network resources actually allocated at time t. η 0 represents a reference ratio for network resource allocation. μ Indicates the deviation adjustment factor. λ This represents the allocation adjustment coefficient.

[0068] Step 402: Based on the migration compensation value and the basic priority of the i-th task, the processing priority of the i-th task is obtained through the task level control function, so as to schedule and execute the processing priorities of each task in the container from high to low.

[0069] In one embodiment, the expression for the task level control function is:

[0070]

[0071]

[0072] in, n This indicates the total number of tasks participating in the scheduling. C i Indicates the first i The execution time of each task T i Indicates the first i The cycle of each task, ω i ( t ) indicates at time t Time i Dynamic weighting factors for each task m Δ represents the total number of task migrations performed. j ( t ) indicates at time t Time j The additional latency caused by each task migration. U crit This represents the critical utilization threshold. ω 0 indicates an initial fixed weight factor. L i ( t ) indicates at time t Time i Migration compensation function for each task, f () represents the dynamic function of the task characteristics. p i ( t ) represents the task level control function. p base Indicates the basic priority of the task. α Represents the periodic dynamic weighting factor. D i Indicates the first i The deadline for each task. β This represents the time weighting factor for the difference. γ This represents the migration compensation factor.

[0073] In one embodiment, This indicates that the overall CPU utilization of a task cannot exceed the overall CPU limit of the system. When migration or preemption occurs before the CPU, the weight factor of the process will be recalculated to achieve CPU utilization limits for individual task processes and overall task processes.

[0074] In one embodiment, after obtaining the processing priority of each task in a container, the tasks can be allocated to CPU cores for execution in descending order of processing priority. High-priority tasks are scheduled and processed first, ensuring sufficient computing resources and timely response even under network congestion or latency fluctuations, thereby effectively guaranteeing service quality.

[0075] Based on the above method, this application discloses a real-time task scheduling system based on Docker containers, referencing... Figure 5 The real-time task scheduling system 1 includes a core partitioning module 11, a data processing module 12, and a level adjustment module 13, wherein... The core partitioning module 11 is used to pre-divide the CPU cores of the target server into dedicated task core pools, wherein the task core pools are functionally isolated from each other, and the number of CPU cores in each task core pool can be dynamically adjusted according to the system load. The data processing module 12 is used to continuously monitor Docker internal events, parse and obtain the business priority and container status of each container in real time, and select and associate the task core pool that best meets the container resource requirements from the core resource pool based on the dynamic container scheduling mapping relationship, according to the business priority and container status of each container. The priority adjustment module 13 is used to continuously monitor the status of the target server during container operation and dynamically adjust the processing priority of tasks within the container to ensure that high-priority tasks can be processed first in the task core pool associated with the container when network congestion or latency fluctuations occur.

[0076] In one example, the core partitioning module 11 is used to obtain the number, model, and current usage of all CPU cores in the target server, and to obtain the number of CPU cores required for real-time tasks and ordinary tasks based on the application type and real-time task requirements; based on the task real-time requirements, task level, and expected load, combined with the number of CPU cores required for real-time tasks and ordinary tasks, the partitioning ratio is obtained and recorded in the preset partitioning policy, and the preset partitioning policy is embedded in the system initialization and Docker container startup scripts; the partitioning ratio, workload, and other information of the real-time task core pool and the ordinary task core pool are periodically polled to adjust the number of CPU cores in the target server, and the adjusted result is written into the preset partitioning policy and stored.

[0077] In one example, the data processing module 12 is used to parse internal events generated in the Docker environment to obtain the unique identifier, container type, task attributes, and business priority of the Docker container corresponding to the internal event; map the container type, task attributes, and business priority of each Docker container to preset scheduling rules to determine the scheduling priority value corresponding to each Docker container and generate container scheduling parameters. The preset scheduling rules include a first mapping table that converts container type and task attributes into basic scheduling weights and a second mapping table that maps business priorities to predetermined scheduling priorities; based on the container scheduling parameters, determine the task core pool that best meets the resource requirements of each Docker container and bind each container to the corresponding task core pool.

[0078] In one example, before parsing the internal events generated in the Docker environment to obtain the unique identifier, container type, task attributes, and business priority of the Docker container corresponding to the internal events, the method further includes: specifying the resource limits of CPU cores, memory, and disk I / O of the Docker container through parameterized configuration when the Docker container is created; recording the running status, port binding relationships, and resource usage of the Docker container and storing the information in a centralized management database; and automatically releasing the port binding relationships when the Docker container is destroyed and synchronously updating the records in the management database.

[0079] In one example, the expression for the dynamic delay function is:

[0080]

[0081]

[0082] in, Delay ( t ) represents the dynamic delay function. B ( t ) indicates at time t The size of the bucket in the token bucket model. r ( t ) indicates at time t The rate at which tokens are generated. B 0 represents the size of the base bucket in the token bucket model. k This represents the adjustment coefficient. Q ( t ) indicates at time t The queue length at that time, Q ref Indicates the reference queue length. r 0 represents the base token generation rate. g () represents the load queue adjustment function. TL ( t ) indicates at time t Network traffic load at that time η ( t The ) represents the proportion of network resources actually allocated at time t. η 0 represents a reference ratio for network resource allocation. μ Indicates the deviation adjustment factor. λ This represents the allocation adjustment coefficient.

[0083] In one example, the expression for the task level control function is:

[0084]

[0085]

[0086] in, n This indicates the total number of tasks participating in the scheduling. C i Indicates the first i The execution time of each task T i Indicates the first i The cycle of each task, ω i ( t ) indicates at time t Time i Dynamic weighting factors for each task m Δ represents the total number of task migrations performed. j ( t ) indicates at time t Time j The additional latency caused by each task migration. U crit This represents the critical utilization threshold. ω 0 indicates an initial fixed weight factor. L i ( t ) indicates at time t Time i Migration compensation function for each task, f () represents the dynamic function of the task characteristics. p i ( t ) represents the task level control function. p base Indicates the basic priority of the task. α Represents the periodic dynamic weighting factor. D i Indicates the first i The deadline for each task. β This represents the time weighting factor for the difference. γ This represents the migration compensation factor.

[0087] In one example, the migration compensation value for the i-th task is calculated using a migration compensation function, the expression of which is: ; in, This represents the migration compensation value for the i-th task. L 0 represents the basic compensation factor under ideal network conditions. Delay ( t ) represents the dynamic delay function. Delay ref This indicates the preset reference delay, when Delay ( t Compensation begins when this value is exceeded. τ This represents the control coefficient, reflecting the effect of the delay excess on the migration compensation function. L i ( t The extent of its impact.

[0088] Please see Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 2 may include at least one processor 21, at least one network interface 24, user interface 23, memory 25, and at least one communication bus 22.

[0089] The communication bus 22 is used to enable communication between these components.

[0090] The user interface 23 may include a display screen and a camera. Optionally, the user interface 23 may also include a standard wired interface and a wireless interface.

[0091] The network interface 24 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0092] The processor 21 may include one or more processing cores. The processor 21 connects to various parts of the server via various interfaces and lines, executing instructions, programs, code sets, or instruction sets stored in the memory 25, and calling data stored in the memory 25 to perform various server functions and process data. Optionally, the processor 21 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 21 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 21 and may be implemented as a separate chip.

[0093] The memory 25 may include random access memory (RAM) or read-only memory. Optionally, the memory 25 may include non-transitory computer-readable storage medium. The memory 25 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 25 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), instructions for implementing the various method embodiments described above, etc.; the data storage area may store data involved in the various method embodiments described above, etc. Optionally, the memory 25 may also be at least one storage device located remotely from the aforementioned processor 21. Figure 6 As shown, the memory 25, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application for a real-time task scheduling method based on Docker containers.

[0094] exist Figure 6 In the electronic device 2 shown, the user interface 23 is mainly used to provide an interface for users to input data and obtain user input data; while the processor 21 can be used to call an application stored in the memory 25 that is a real-time task scheduling method based on Docker containers. When executed by one or more processors, the electronic device executes one or more methods as described in the above embodiments.

[0095] A computer-readable storage medium storing instructions that, when executed by one or more processors, cause a computer to perform one or more methods as described in the above embodiments.

[0096] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0097] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0098] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some service interfaces; indirect couplings or communication connections between apparatuses or units may be electrical or other forms.

[0099] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0100] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0101] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0102] The above are merely exemplary embodiments of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the specification and the disclosure of practical truths. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.< / pid>

Claims

1. A real-time task scheduling method based on Docker containers, characterized in that, Installing a Docker environment on the target server, the method includes: The CPU cores of the target server are pre-divided into multiple task core pools, wherein the task core pools are functionally isolated from each other, and the number of CPU cores in each task core pool can be dynamically adjusted according to the system load. Continuously monitor Docker internal events, parse and obtain the business priority and container status of each container in real time, and select and bind the task core pool that best meets the container resource requirements for each container based on the business priority and container status of each container and the dynamic container scheduling mapping relationship. During container operation, the status of the target server is continuously monitored, and the processing priority of tasks within the container is dynamically adjusted to ensure that high-priority tasks are processed first in the task core pool that the container is bound to when network congestion or latency fluctuations occur.

2. The real-time task scheduling method based on Docker containers as described in claim 1, characterized in that, The step of pre-dividing the CPU cores of the target server into dedicated task core pools, wherein the task core pools are functionally isolated from each other, and the number of CPU cores in each task core pool can be dynamically adjusted according to the system load, includes: Obtain the number, model, and current usage of all CPU cores in the target server, and calculate the number of CPU cores required for real-time tasks and ordinary tasks based on the application type and real-time task requirements. Based on the task's real-time requirements, task level, and expected load, combined with the number of CPU cores required for real-time tasks and ordinary tasks, the partition ratio between the real-time task core pool and the ordinary task core pool is determined, and the partition ratio is recorded in the preset partitioning strategy and embedded in the system initialization and Docker container startup scripts. The system periodically polls the real-time task core pool and the ordinary task core pool to adjust the number of CPU cores in the target server based on the partition ratio, workload, and other factors of the task core pool. The adjusted results are then written into the preset partitioning strategy and stored.

3. The real-time task scheduling method based on Docker containers as described in claim 1, characterized in that, The method further includes: Parse the internal events generated in the Docker environment to obtain the unique identifier, container type, task attributes, and business priority of the Docker container corresponding to the internal event; The container type, task attributes, and business priority of each Docker container are mapped to preset scheduling rules to determine the scheduling priority value corresponding to each Docker container and generate container scheduling parameters. The preset scheduling rules include a first mapping table that converts container type and task attributes into basic scheduling weights and a second mapping table that maps business priorities to predetermined scheduling priorities. Based on the container scheduling parameters, determine the task core pool that best meets the resource requirements of each Docker container, and bind each container to the corresponding task core pool.

4. The real-time task scheduling method based on Docker containers as described in claim 1, characterized in that, The method includes: For the i-th task in a container, the migration compensation value of the i-th task at time t is calculated using a dynamic delay function; Based on the migration compensation value and the basic priority of the i-th task, the processing priority of the i-th task is obtained through the task level adjustment function, so as to schedule and execute the processing priorities of each task in the container from high to low.

5. The real-time task scheduling method based on Docker containers as described in claim 4, characterized in that, The expression for the task level control function is: ； ； ； in, n This indicates the total number of tasks participating in the scheduling. C i Indicates the first i The execution time of each task T i Indicates the first i The cycle of each task, ω i ( t ) indicates at time t Time i Dynamic weighting factors for each task m Δ represents the total number of task migrations performed. j ( t ) indicates at time t Time j The additional latency caused by each task migration. U crit This represents the critical utilization threshold. ω 0 indicates an initial fixed weight factor. L i ( t ) indicates at time t Time i Migration compensation function for each task, f () represents the dynamic function of the task characteristics. p i ( t ) represents the task level control function. p base Indicates the basic priority of the task. α Represents the periodic dynamic weighting factor. D i Indicates the first i The deadline for each task. β This represents the time weighting factor for the difference. γ This represents the migration compensation factor.

6. The real-time task scheduling method based on Docker containers as described in claim 4, characterized in that, The migration compensation value for the i-th task is calculated using the migration compensation function, which is expressed as follows: ； in, This represents the migration compensation value for the i-th task. L 0 represents the basic compensation factor under ideal network conditions. Delay ( t ) represents the dynamic delay function. Delay ref Indicates the preset reference delay, when Delay ( t Compensation begins when this value is exceeded. τ This represents the control coefficient, reflecting the effect of the delay exceeding the migration compensation function. L i ( t The extent of its impact.

7. The real-time task scheduling method based on Docker containers as described in claim 4, characterized in that, The expression for the dynamic delay function is: ； ； ； in, Delay ( t ) represents the dynamic delay function. B ( t ) indicates at time t The size of the bucket in the token bucket model. r ( t ) indicates at time t The rate at which tokens are generated. B 0 represents the size of the base bucket in the token bucket model. k This represents the adjustment coefficient. Q ( t ) indicates at time t The queue length at that time, Q ref Indicates the reference queue length. r 0 represents the base token generation rate. g () represents the load queue adjustment function. TL ( t ) indicates at time t Network traffic load at that time η ( t The ) represents the proportion of network resources actually allocated at time t. η 0 represents a reference ratio for network resource allocation. μ Indicates the deviation adjustment factor. λ This represents the allocation adjustment coefficient.

8. The real-time task scheduling method based on Docker containers as described in claim 3, characterized in that, Before parsing the internal events generated in the Docker environment to obtain the unique identifier, container type, task attributes, and business priority of the Docker container corresponding to the internal event, the process also includes: When a Docker container is created, you can specify the resource limits for CPU cores, memory, and / or disk I / O of the Docker container through parameterized configuration. Record the running status, port binding relationships, and resource usage of Docker containers, and store the information in a centralized management database; When a Docker container is destroyed, the port bindings are automatically released, and the records in the management database are updated synchronously.

9. A real-time task scheduling device based on Docker containers, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the processor for performing the real-time task scheduling method based on Docker containers as described in any one of claims 1-8.

10. A non-volatile computer storage medium, characterized in that, The computer storage medium stores computer-executable instructions, which are executed by one or more processors to perform the real-time task scheduling method based on Docker containers as described in any one of claims 1-8.

Images