Processor time scheduling and container creation method, device, medium, and program product

Abstract

Embodiments of the present disclosure provide a processor time scheduling and container creation method, a device, a medium, and a program product. In the embodiments of the present disclosure, in order to implement flexible processor bandwidth control in a secure container, by means of extending a virtual processor core allocated to a conventional secure container, a constraint requiring one-to-one correspondence between usage duration (Quota) in the conventional secure container and virtual processor cores is broken, and the secure container can use the extended virtual processor core to consume unconsumed duration accumulated by a historical scheduling cycle under a high load, so that flexible processor bandwidth control is implemented, thereby meeting burst load demand and improving service quality of the secure container.

Description

Processor time scheduling and container creation methods, devices, media and program products

[0001] This disclosure claims priority to Chinese Patent Application No. 202411545067.3, filed with the China Patent Office on October 31, 2024, entitled “Processor Time Scheduling and Container Creation Method, Apparatus, Media and Program Product”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the field of computer technology, and in particular to a processor time scheduling and container creation method, apparatus, medium and program product. Background Technology

[0003] With the development of cloud computing technology, container technology plays an important role in realizing multi-tenant environments. Container technology allows multiple isolated application instances to run on the same host machine, thereby improving resource utilization and deployment efficiency.

[0004] When handling bursty tasks on the Central Processing Unit (CPU), traditional shared containers can provide good quality of service through elastic CPU bandwidth control technology, but this poses significant security risks. To continue providing high-quality service while ensuring security, secure containers are widely used. However, existing secure containers cannot utilize elastic CPU bandwidth control technology. Summary of the Invention

[0005] This disclosure provides, in several aspects, a processor time scheduling and container creation method, apparatus, media, and program products for implementing resilient processor bandwidth control in secure containers.

[0006] This disclosure provides a processor time scheduling method, including:

[0007] When the load on the virtual processor of the secure container meets the high load condition, the first unused duration accumulated by the virtual processor of the secure container in the historical scheduling cycle is obtained; the virtual processor has a target number of virtual processor cores; the target number is obtained by expanding on the first number; the first number is determined according to the resource request amount and resource limit amount of the secure container;

[0008] The first duration is consumed by the target number of virtual processor cores to execute tasks using physical processors.

[0009] This disclosure also provides a container creation method, including:

[0010] Obtain a container creation request, which is used to request the creation of a secure container, and the container creation request includes the resource request amount and the resource limit amount;

[0011] The number of virtual processor cores of the security container is determined based on the resource request amount and the resource limit amount, and is used as the first quantity;

[0012] The first quantity is expanded to obtain the target quantity;

[0013] Based on the target number of virtual processor cores, create virtual machine instances on the host machine;

[0014] The secure container is created on the virtual machine instance to perform tasks using the target number of virtual processor cores, consuming the previously accumulated unused processor time of the secure container, when the virtual processor load of the secure container meets high load conditions.

[0015] This disclosure also provides an electronic device, including: a memory and a processor; wherein the memory is used to store a computer program;

[0016] The processor is coupled to the memory and is used to execute the computer program for performing the steps in the aforementioned processor time scheduling method and / or container creation method.

[0017] This disclosure also provides a computer-readable storage medium storing computer instructions that, when executed by one or more processors, cause the one or more processors to perform the steps in the aforementioned processor time scheduling method and / or container creation method.

[0018] This disclosure also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps in the aforementioned processor time scheduling method and / or container creation method.

[0019] In this embodiment of the disclosure, in order to achieve elastic processor bandwidth control within a secure container, the virtual processor cores allocated to a traditional secure container are expanded. This breaks the limitation that the usage time (Quota) and virtual processor cores in a traditional secure container need to be matched one-to-one. Under high load, the secure container can utilize the expanded virtual processor cores to consume the unused time accumulated in the historical scheduling cycle, thereby achieving elastic processor bandwidth control. This helps to meet bursty load demands and improve the service quality of the secure container. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this disclosure, illustrate exemplary embodiments of the present disclosure and are used to explain the disclosure, but do not constitute an undue limitation of the disclosure. In the drawings:

[0021] Figures 1a and 1b are schematic flowcharts of the container creation method provided in the embodiments of this disclosure;

[0022] Figure 2 is a flowchart illustrating the processor time scheduling method provided in an embodiment of this disclosure;

[0023] Figure 3 is an architecture diagram of the secure container provided in an embodiment of this disclosure;

[0024] Figure 4 is a schematic diagram of the hiding mechanism of the extended virtual processor core provided in the embodiments of this disclosure;

[0025] Figure 5 is a schematic diagram of the mapping mechanism of the extended virtual processor core provided in the embodiments of this disclosure;

[0026] Figure 6 is a schematic diagram of the structure of the electronic device provided in the embodiment of this disclosure. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0028] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0029] The terms or concepts involved in the embodiments of this disclosure will be explained below.

[0030] Traditional containers: These containers achieve runtime isolation using resource control groups (Cgroups) and namespaces. A key characteristic is that the container shares the kernel with the host machine. Cgroups are a mechanism provided by the operating system (OS) kernel for managing and controlling the resources used by process groups. They can limit, record, and isolate the physical resources used by process groups. Physical resources can include processor resources, memory resources, and disk input / output (I / O) resources. It allows system administrators or process schedulers to assign processes to different resource control groups (Cgroups) and then set resource limits, priorities, or accounting for these groups. Cgroups are one of the core components of container technology. Cgroups improve resource utilization and isolation in server and container environments and are one of the foundations for lightweight virtualization technology.

[0031] Secure Containers: Secure containers are an enhanced container technology that provides a higher level of security isolation than traditional containers. Compared to traditional containers, secure containers offer stronger security and isolation by introducing a virtualization layer. Secure containers typically use lightweight virtualization technology to completely isolate the container's runtime environment from the host machine's kernel. This isolation ensures that applications within the container do not directly affect the host machine or other containers, reducing the risk of security vulnerabilities. Secure containers use a separate virtualization kernel, rather than sharing it with the host machine, thus preventing potential kernel-level attacks. Each container has its own virtualization kernel instance, so even if a security incident occurs inside the container, it will not affect the host machine or other containers.

[0032] Shared secure containers: adopt an unbound CPU scheduling mode, where each virtual CPU (vCPU) is randomly assigned to any idle physical CPU, and different vCPUs will compete for physical CPU resources.

[0033] Elastic CPU bandwidth control: By accumulating unused CPU time during each scheduling cycle when the CPU is relatively idle, this accumulated time can be used during periods of high CPU load, thereby exceeding the original processor quota limit and improving service quality. This method is particularly effective when handling bursty CPU tasks with low average CPU utilization but high CPU utilization during certain periods.

[0034] CPU Quota: Processor quotas, such as CPU quota policies, are used to limit the total amount of processor (e.g., CPU) time a container can use within a certain period. When a container's limit sets processor resources, a processor quota policy (such as CPU Quota) can be set in a resource control group (Cgroup) to limit the container's processor resource usage. Specifically, a container's limit can be converted into a processor quota policy (such as CPU Quota) in a resource control group (Cgroup), thereby limiting the amount of time a container can use processors within a certain period.

[0035] The following explains why secure containers cannot use elastic bandwidth control technology.

[0036] Traditional containers excel in resource management and scheduling, but because they share the host kernel, a malicious attack can allow attackers to directly escape to the host kernel, affecting all containers on that host and posing a serious security risk. Therefore, for services with high security requirements, the current mainstream trend is to migrate to secure containers. Secure containers introduce a lightweight virtualization layer to isolate the container's kernel from the host kernel, achieving mutual independence between the container and the host. This isolation mechanism significantly improves security, but it also introduces new challenges.

[0037] In a secure container, each virtual processor core corresponds to a process on the host machine; therefore, the tasks running within the container are limited by the number of virtual processor cores. This means that the container specification indicates not only the upper limit of processor resources that the container can use, but also the number of virtual processor cores within the container. A virtual processor core refers to a logical core. One physical core can be virtualized into one or more logical cores. Multiple refers to two or more (including two).

[0038] Some container cluster management systems, such as Kubernetes (K8s), use processor (e.g., CPU) request (request.cpu) and limit (limit.cpu) parameters to allocate and control the CPU resources of containers. Request (request.cpu) represents the weight value of the time slice allocated to this container, which is the minimum processor resource guarantee for the container. Request (request.cpu) refers to the minimum amount of CPU resources that the container expects to obtain. Limit (limit.cpu) represents the hard upper limit of the CPU time that the container can use. For example, request.cpu = 1, limit.cpu = 4 means that when there is more than 1 idle CPU time on the host machine, the container can be scheduled, but the maximum CPU time that the container can use is no more than 4 CPU time. When creating a secure container, the two parameters request (request.cpu) and limit (limit.cpu) are used to determine the number of cores of the virtual processor (vCPU), also known as the number of virtual processors. The calculation method is as follows: nr_vcpu = max(request.cpu, limit.cpu) (1).

[0039] Where nr_vcpu represents the number of virtual processor cores; max(request.cpu,limit.cpu) represents taking the maximum value of the request (request.cpu) and the limit (limit.cpu).

[0040] Furthermore, the control plane of a secure container, such as the runtime component, can create virtual machines based on this calculation result. The number of processor cores in a virtual machine is equal to nr_vcpu, and each virtual processor core corresponds to a process on the host machine. The runtime component is responsible for managing the container's lifecycle, including creating, starting, stopping, and destroying containers. A container is an independent runtime environment created by the container runtime from a container image.

[0041] Then, the secure container control plane sets a processor quota for the secure container, limiting the maximum amount of time it can use for processors (such as CPUs), calculated as follows: cpu.quota = nr_vcpu * cpu.period (2).

[0042] Here, cpu.quota represents the maximum amount of processor time that the container can use; cpu.period represents the CPU scheduling period, which is equal to one unit of CPU time.

[0043] Combining the two formulas above, it can be seen that when a secure container's control plane (such as runtime components) creates a secure container, it directly maps processor quotas to virtual processor cores on a one-to-one basis. This directly limits the unused CPU time accumulated when the secure container's CPU is relatively idle, preventing it from being consumed during CPU busy periods. Because there are no spare virtual processor cores to consume previously accumulated unused CPU time during CPU busy periods in a secure container, elastic CPU bandwidth control technology cannot take effect in secure containers. However, the average CPU utilization of secure containers is not high, while bursty CPU loads with high CPU utilization during certain periods are common. Therefore, to improve the quality of service for bursty CPU loads within secure containers, secure containers need to support elastic CPU bandwidth control technology.

[0044] In some embodiments of this disclosure, in order to achieve elastic processor bandwidth control within a secure container, the virtual processor cores allocated to a traditional secure container are expanded. This breaks the limitation that the usage time (Quota) and virtual processor cores in a traditional secure container need to be matched one-to-one. Under high load, the secure container can utilize the expanded virtual processor cores to consume the unused time accumulated in historical scheduling cycles, thereby achieving elastic processor bandwidth control. This helps to meet bursty load demands and improve the service quality of the secure container.

[0045] The technical solutions provided by the embodiments of this disclosure are described in detail below with reference to the accompanying drawings.

[0046] It should be noted that the same reference numerals denote the same object in the following figures and embodiments. Therefore, once an object is defined in one figure or embodiment, it does not need to be discussed further in subsequent figures and embodiments.

[0047] Figure 1a is a flowchart illustrating the container creation method provided in this embodiment of the present disclosure. As shown in Figure 1a, the method mainly includes:

[0048] 101. Obtain the container creation request. The container creation request is used to request the creation of a secure container. The container creation request includes the resource request amount and resource limit amount.

[0049] 102. Based on the resource request volume and resource limit, determine the number of virtual processor cores for the security container as the first quantity.

[0050] 103. Expand the first quantity to obtain the target quantity.

[0051] 104. Create virtual machine instances on the host machine according to the target number of virtual processor cores.

[0052] 105. Create a secure container on the virtual machine instance to execute tasks using a target number of virtual processor cores, consuming the previously accumulated unused processor time of the secure container, when the virtual processor load of the secure container meets high load conditions.

[0053] In this embodiment of the disclosure, the container creation request is used to request the creation of a secure container, and includes: a resource request amount (Request) and a resource limit (Limit). The resource request amount (Request) is the minimum amount of resources that the secure container can obtain, representing the minimum resource guarantee for the secure container. The resource request amount (Request) refers to the minimum amount of resources the container expects to obtain. The scheduler allocates sufficient resources to the secure container based on its resource request amount (Request). The maximum resource information that the secure container can use can be determined using the secure container's resource limit (Limit). The container's resource limit (Limit) refers to the maximum amount of resources the container can use. The container's resource usage must not exceed this limit. The resource request amount includes the aforementioned processor request (request.cpu); the resource limit includes processor limits (such as limit.cpu).

[0054] In some embodiments, a container creation request may include a configuration file, such as a YAML file, for the secure container to be created. The YAML file includes the aforementioned resource request amount and resource limits. The YAML file provides a concise way to describe the configuration data structure of a secure container, making it well-suited for configuring and managing containers.

[0055] After obtaining the container creation request in step 101, in step 102, the number of virtual processor cores for the secure container can be determined based on the resource request amount and the resource limit. Specifically, the maximum value between the processor request and the processor limit can be selected as the number of virtual processor cores for the secure container, i.e., nr_vcpu = max(request.cpu, limit.cpu). This number of virtual processor cores for the secure container can be referred to as the standard number of virtual processor cores for the secure container.

[0056] In this embodiment, to enable the secure container to support processor elastic control technology, the standard number of virtual processor cores in the secure container can be expanded. The expanded number of virtual processor cores can be used to consume the processor time accumulated by the secure container's processors during idle time when the secure container is under high load. Therefore, in step 103, the number of virtual processor cores in the secure container can be expanded to obtain a target number. The target number refers to the expanded number of virtual processor cores. In this embodiment, for ease of description and distinction, the standard number of virtual processor cores in the secure container determined in step 102 is defined as the first number; the number of virtual processor cores expanded from the standard number is defined as the second number, and the target number is equal to the first number plus the second number.

[0057] In this disclosure, the specific implementation of expanding the first quantity is not limited. In some embodiments, the user of the secure container can specify the expansion factor (burst_vcpu_factor). Accordingly, the container creation request may include the expansion factor. The expansion factor may also be located in the configuration file of the secure container, such as a yaml file. That is, a parameter corresponding to the expansion factor is added to the configuration file, and the user can specify the expansion factor by assigning a value to the parameter. The expansion factor is greater than or equal to 1. Generally, the expansion factor is an integer. Since the secure container is a normal secure container when the expansion factor is equal to 1, it cannot use the elastic processor bandwidth control technology. Therefore, this disclosure focuses on the expansion factor being greater than 1. Based on the expansion factor, step 103 can be implemented as: expanding the first quantity according to the expansion factor to obtain the target quantity. Specifically, the product of the first quantity and the expansion factor can be used as the target quantity. Accordingly, the target quantity can be expressed as: nr_burst_vcpu = nr_vcpu * burst_vcpu_factor, burst_vcpu_factor≥1 (3).

[0058] Where nr_burst_vcpu represents the target number of virtual processor cores; burst_vcpu_factor represents the expansion factor.

[0059] In this embodiment, the determination of whether to use the container creation method provided in this disclosure to create a secure container can be made based on whether the configuration file of the secure container carries a parameter corresponding to the expansion factor (such as burst_vcpu_factor).

[0060] In other embodiments, a predetermined quantity can be added to the first quantity to obtain the target quantity. Alternatively, the first quantity can be multiplied by a predetermined multiple to obtain the target quantity. The predetermined multiple is greater than 1. In these embodiments, a parameter can be added to the secure container's configuration file to indicate whether the secure container is created using the container creation method provided in this disclosure. If the value of this parameter indicates that the secure container is created using the container creation method provided in this disclosure, then the secure container is created using the container creation method provided in this disclosure; if the value of this parameter indicates that the secure container is not created using the container creation method provided in this disclosure, then the secure container is created using the conventional secure container creation method provided in the foregoing embodiments.

[0061] Furthermore, in step 104, virtual machine instances can be created on the host machine according to the target number of virtual processor cores. Specifically, kernel-based virtual machine (KVM) technology can be used to create virtual machines on the host machine, and the target number of virtual processor cores and other resources can be configured for the virtual machines to obtain virtual machine instances. These other resources include, but are not limited to, memory resources, persistent storage resources, and network resources. KVM is a virtualization technology under an operating system (such as Linux), which can transform the operating system into a virtual machine monitor, enabling the host computer to run multiple isolated virtual environments.

[0062] Furthermore, in step 105, a secure container can be created on the virtual machine instance so that the virtual processor of the secure container has a target number of virtual processor cores. Creating a secure container on the virtual machine instance allows the secure container to run a separate kernel, ensuring the reliability of the secure container.

[0063] Specifically, a container image of the secure container to be created can be loaded onto a virtual machine instance; and a secure container can be created on the virtual machine instance based on the container image. More specifically, the code in the container image can be run on a virtual machine instance created by KVM, thereby creating a secure container on the virtual machine instance, allowing the secure container to run on an independent kernel created by KVM.

[0064] It is worth noting that the secure containers involved in the embodiments of this disclosure can be either shared or exclusive. For shared secure containers, each virtual processor core within the secure container is a process and is not bound to a physical virtual processor core. The maximum available processor time for the secure container is limited by the processor quota (cpu.quota), resulting in low or even no processor resource waste. In exclusive secure containers, each virtual processor core is bound to a physical virtual processor core. If the processor time scheduling method provided in the embodiments of this disclosure is applied to exclusive secure containers, it will introduce significant processor resource waste. Therefore, the secure containers in the embodiments of this disclosure mainly refer to shared secure containers. In some embodiments of this disclosure, in addition to obtaining the resource request amount, resource limit amount, and expansion multiple from the secure container's configuration file, it is also possible to configure whether the secure container is shared or exclusive in the secure container's configuration file. Accordingly, as shown in Figure 1b, it is also possible to obtain whether the secure container is a shared secure container from the secure container's configuration file. If so, the container creation method provided in this embodiment is used to create a secure container, i.e., as shown in Figure 1b, the number of virtual processor cores of the secure container, i.e., the first quantity, is determined based on the resource request amount and resource limit amount. Specifically, the aforementioned formula (1) can be used to determine this. Furthermore, the aforementioned formula (3) can be used to expand the number of virtual processor cores of the secure container to obtain the target number of virtual processor cores. The aforementioned formula (2) can also be used to determine the limited usage time of the secure container (e.g., cpu.quota). Furthermore, a secure container can be created based on the target number of virtual processor cores; and the limited usage time of the secure container (e.g., cpu.quota) can be set. Correspondingly, if the secure container is an exclusive secure container, the secure container creation method shown above can be used to create the secure container. Specifically, the aforementioned formula (1) can be used to determine the number of virtual processor cores of the secure container, i.e., the first quantity; and the aforementioned formula (2) can be used to determine the limited usage time of the secure container (e.g., cpu.quota). Furthermore, a secure container can be created based on the first number of virtual processor cores; and the limited usage time of the secure container (e.g., cpu.quota) can be set.

[0065] For a completed shared security container, it has a target number of virtual processor cores, which is greater than the number of virtual processor cores determined based on resource requests and resource limits. This provides a prerequisite for using elastic processor bandwidth control when the virtual processor load of the security container meets high load conditions.

[0066] In some embodiments, the secure container may support Elastic Processor Bandwidth Control (EPB) technology by default. In other embodiments, EPB can be enabled within the secure container after it has been created. Because the secure container introduces a virtualization layer, it is isolated from the host kernel. Therefore, EPB needs to be enabled simultaneously at both the secure container and host levels for it to take effect within the secure container.

[0067] Specifically, specific command-line parameters can be added to the secure container's configuration file (such as a YAML file) to instruct the guest operating system (Guest OS) to enable Elastic Processor Bandwidth Control (ECB). The guest operating system refers to the operating system of the virtual machine instance where the secure container resides. Command-line parameters are the configuration options passed to the kernel at startup, either during the boot process or the kernel. When starting the secure container, ECB can be enabled using command-line parameters. Specifically, a command line, such as "elastic_cpu=on", can be added to the secure container's configuration file to instruct the guest operating system to enable ECB. During the secure container creation process, this command line is passed to the guest operating system via a container management tool (such as KVM). The guest operating system can then use this command line to enable ECB, thus enabling ECB at the secure container level.

[0068] This is achieved at the host level through the virtual processor core expansion mechanism of secure containers. Specifically, during the creation of a secure container, the host operating system can initiate the elastic processor bandwidth control function via command line.

[0069] After enabling elastic processor bandwidth control at both the secure container and host levels, elastic processor bandwidth control can be achieved through the expansion of a target number of virtual processor cores. The following describes in detail the processor time scheduling method provided in this disclosure embodiment to implement elastic processor bandwidth control.

[0070] Figure 2 is a flowchart illustrating the processor time scheduling method provided in this embodiment of the present disclosure. As shown in Figure 2, the method mainly includes the following steps:

[0071] 201. When the load of the virtual processor of the secure container meets the high load condition, obtain the first unused duration of the virtual processor of the secure container accumulated in the historical scheduling cycle.

[0072] The virtual processor has a target number of virtual processor cores; the target number is obtained by extending the first number; the first number is determined based on the resource request and resource limit of the secure container. For details on how the first number and the target number are determined, please refer to the relevant content in the foregoing embodiments, which will not be repeated here.

[0073] 202. Use the physical processor to execute tasks by consuming the first duration through the target number of virtual processor cores.

[0074] In this embodiment, for any scheduling period X, a target number of virtual processor cores can be invoked to execute the tasks of scheduling period X; and the total time T consumed by the target number of virtual processor cores to complete the tasks of scheduling period X is calculated. x If the total time consumed by the target number of virtual processor cores to complete the tasks in scheduling period X is less than the usage limit, then the unused time of the target number of virtual processor cores in scheduling period X will be added to the accumulated unused time, resulting in the accumulated unused time for scheduling period X.

[0075] The usage time limit refers to the maximum time that the secure container can use the physical processor, which is equal to the first quantity multiplied by the call cycle, i.e.: cpu.quota = nr_vcpu * cpu.period (4).

[0076] Here, cpu.quota refers to the maximum amount of processor time that a secure container can use, i.e., the time limit for its use.

[0077] The target number of virtual processor cores in the time t not consumed during scheduling cycle X x It equals the limited usage time minus the total time T consumed by the target number of virtual processor cores to complete the task in the scheduling cycle X. x That is, t x =cpu.quota-T x Correspondingly, the unconsumed cumulative duration T corresponds to the scheduling period X. Xa It can be represented as: i represents the i-th scheduling cycle. t i This represents the time that the target number of virtual processor cores has not consumed in the i-th scheduling cycle X.

[0078] Accordingly, if the total time consumed by the target number of virtual processor cores to complete the tasks of the scheduling period X is greater than or equal to the limited usage time, then it is determined that the load of the virtual processor of the security container meets the set high load condition, and the processor time scheduling method provided in the embodiments of this disclosure is used in the next scheduling period (X+1) of the scheduling period X.

[0079] For the previous scheduling period (k-1) of the current scheduling period k, if the total time consumed by the target number of virtual processor cores to complete the tasks in the previous scheduling period (k-1) reaches the usage limit corresponding to the secure container, then the load of the virtual processors of the secure container is determined to meet the set high load condition. Accordingly, in this embodiment, the set high load condition is implemented as follows: the total time consumed by the target number of virtual processor cores to complete the tasks in the previous scheduling period (k-1) reaches the usage limit corresponding to the secure container.

[0080] In other embodiments, the processor utilization of the secure container can also be monitored. The processor utilization reflects the processor load level. If the processor utilization of the secure container is greater than or equal to a set utilization threshold, it is determined that the load of the virtual processor of the secure container meets a set high-load condition. Accordingly, in this embodiment, the set high-load condition is implemented as: the processor utilization of the secure container is greater than or equal to a set utilization threshold.

[0081] Furthermore, the processor time scheduling method provided in this disclosure embodiment can be used in the current scheduling period k. Specifically, the unused time accumulated by the virtual processor of the security container in historical scheduling periods can be obtained. In this disclosure embodiment, the scheduling periods before the current scheduling period are referred to as historical scheduling periods. Wherein, if the current scheduling period k is the first scheduling period after detecting that the load of the virtual processor of the security container meets the set high load condition, the unused time accumulated by the virtual processor of the security container in historical scheduling periods can be expressed as: That is, the unused time accumulated by the virtual processor of the secure container in the historical scheduling cycle is equal to the unused accumulated time corresponding to the (k-1)th scheduling cycle.

[0082] If the current scheduling period k is any scheduling period after the load on the virtual processor of the secure container is detected to meet the set high load condition, then the unused time accumulated by the virtual processor of the secure container in historical scheduling periods is equal to the unused accumulated time corresponding to the scheduling period after the load on the virtual processor of the secure container was detected to meet the set high load condition, minus the time consumed in the scheduling periods after the load on the virtual processor of the secure container was detected to exceed the limited usage time (e.g., cpu.quota) corresponding to that secure container. The limited usage time (e.g., cpu.quota) refers to the upper limit of the time the secure container uses the physical processor.

[0083] For example, suppose the scheduling period in which the load of the virtual processor of the security container meets the set high load condition is the (kj)th scheduling period, and the unused cumulative time corresponding to the (kj)th scheduling period can be expressed as T. (k-j)aThen the unused time accumulated by the virtual processor of the secure container in historical scheduling cycles is equal to Among them, T i2 This represents the duration consumed during the i-th scheduling cycle that exceeds the usage limit (e.g., cpu.quota) corresponding to the safe container.

[0084] Furthermore, by using a target number of virtual processor cores, the unused time accumulated by the virtual processors in historical scheduling cycles can be consumed to use physical processors to execute tasks.

[0085] In this embodiment, by expanding the logical cores (i.e., virtual processor cores) allocated to traditional secure containers, the limitation that the usage time (Quota) and virtual processor cores in traditional secure containers need to be matched one-to-one is broken. Under high load, the secure container can use the expanded virtual processor cores, i.e. the expanded logical cores, to consume the unused time accumulated in the historical scheduling cycle, thereby achieving elastic processor bandwidth control. This helps to meet the demands of bursty loads and improve the service quality of secure containers.

[0086] Specifically, for the current scheduling period k, the duration during which the virtual processor can exceed the physical processor's usage limit in the current scheduling period k can be obtained from the unused time accumulated by the virtual processor in historical scheduling periods. In this embodiment of the disclosure, for ease of description and distinction, the unused time accumulated by the virtual processor of the security container in historical scheduling periods is defined as the first duration; and the duration during which the virtual processor can exceed the physical processor's usage limit in the current scheduling period k is defined as the second duration T. k2 .

[0087] In some embodiments, the second duration T can be determined based on the expansion factor and the limited usage time corresponding to the security container. k2 The expansion factor is equal to the target quantity divided by the aforementioned first quantity. Specifically, the product of the expansion factor and the limited usage time (Quota) can be calculated as the total time that the virtual processor of the secure container can use the physical processor in the current scheduling period k; further, the difference between the total time that the virtual processor of the secure container can use the physical processor in the current scheduling period k and the limited usage time can be calculated as the time that the virtual processor can exceed the limit to use the physical processor in the current scheduling period k, i.e., the second duration T. k2 Because the number of virtual processor cores in a secure container is increased by a factor of several, the total time that the virtual processors in a secure container can use physical processors in the current scheduling period k is also increased by a factor of several compared to the limited usage time (Quota). This allows the additional virtual processors to have enough physical processor time to execute tasks, thereby improving overall performance.

[0088] Furthermore, the second duration T can be obtained from the first duration of unused time accumulated by the virtual processor of the secure container during historical scheduling cycles. k2 Then, a second duration T can be added to the limited usage time (e.g., cpu.quota) corresponding to the secure container. k2 The target duration is calculated as follows: target duration = cpu.quota + T k2 .

[0089] Furthermore, a target duration can be allocated to a target number of virtual processor cores, allowing the target number of virtual processor cores to use the physical processor to execute tasks in the current scheduling period k within the allocated time.

[0090] Specifically, the constraint can be that the sum of the time allocated to the target number of virtual processor cores equals the target duration. Based on the resource requirements of the tasks executed by each virtual processor core in the current scheduling cycle, the allocated duration for each virtual processor core can be determined.

[0091] Optionally, for each virtual processor core, the processor time required for executing a task by that virtual processor core can be collected within the current scheduling period k. Resource requirements can be expressed as a percentage of processor time, an absolute value of processor time, or other metrics. Further, the weight of the target number of virtual processor cores can be calculated based on the processor time required for the target number of virtual processor cores to execute tasks. The weight of any virtual processor core can be equal to the percentage of the processor time required for that virtual processor core to execute tasks relative to the sum of the processor times required for the target number of virtual processor cores to execute tasks. Further, the allocated time for each virtual processor core corresponding to the target number of virtual processor cores can be determined based on its weight. The allocated time for any virtual processor core is equal to its weight multiplied by the target time.

[0092] Furthermore, a corresponding unallocated time can be allocated to each virtual processor core to allocate a target time to the target number of virtual processor cores. In this way, each virtual processor core can execute the task of the current scheduling period k within its allocated time, realizing the elastic processor bandwidth control of the secure container, which helps to meet the burst load demand and improve the service quality of the secure container.

[0093] After allocating the target time duration to the target number of virtual processor cores, a second time duration can be subtracted from the stored first time duration to obtain a new, unused time duration accumulated by the virtual processors in historical scheduling cycles. This new time duration is used for processor time scheduling in the next scheduling cycle until the accumulated unused time duration is exhausted. After the accumulated unused time duration is exhausted, the target number of virtual processor cores can continue to be allocated a limited usage time duration, with the constraint that the total time allocated to the target number of virtual processor cores equals the limited usage time duration. In this way, each virtual processor core can execute the task of the corresponding scheduling cycle within its allocated time.

[0094] In some embodiments, the first unused duration of the virtual processor of the security container obtained in the current scheduling period k over historical scheduling periods may be less than the previously determined second duration T. k2 Then, a first duration can be added to the limited usage time (cpu.quota) corresponding to the secure container, which is the total time allocated to the target number of virtual processor cores in the current scheduling cycle (defined as the fourth duration). Furthermore, the target number of virtual processor cores can be allocated this fourth duration. In this way, the target number of virtual processor cores use the physical processors to execute tasks in the current scheduling cycle k within the allocated time, realizing elastic processor bandwidth control for the secure container, which helps meet bursty load demands and improves the service quality of the secure container.

[0095] For details on the specific implementation of allocating a fourth duration of time to a target number of virtual processor cores, please refer to the aforementioned content on allocating a target duration of time to a target number of virtual processor cores, which will not be repeated here.

[0096] Because elastic processor bandwidth control technology allows unused processor time within each scheduling cycle to be accumulated and used during periods of high processor load, it can exceed the processor quota (cpu.quota) limit of secure containers during high load periods, thereby improving the quality of service (QoS) of secure containers. However, this may exacerbate competition for processor resources among containers on the same host, thus affecting the QoS of neighboring containers of the secure container. Neighboring containers of a secure container refer to other containers deployed on the same host as the secure container and sharing the host's physical processors. Therefore, priority should be given to ensuring that the processor quota (cpu.quota) of neighboring containers is met, and only then should the need for the secure container to exceed its processor quota (cpu.quota) be met. Based on this, in some embodiments of this disclosure, as shown in Figure 3, a dynamic adjustment mechanism for the scheduling weight of secure containers is introduced.

[0097] Specifically, the scheduling weights of each container deployed on the host machine (including security containers and other containers deployed on the host machine) can be pre-configured. The pre-configured scheduling weights of each container can be the same or different. In some embodiments, the pre-configured scheduling weights of each container can be the same, equal to 1 / N. N represents the total number of containers deployed on the host machine, including security containers and other containers deployed on the host machine. In other embodiments, the scheduling weights of each container can be configured based on the limited usage time of each container deployed on the host machine. Specifically, for any container A, the ratio of the limited usage time of container A to the sum of the limited usage times of all containers can be calculated as the scheduling weight of container A. Alternatively, the limited usage time of container A can be used as the scheduling weight of container A. The aforementioned configured scheduling weights of the containers are the initial scheduling weights of the containers.

[0098] If the virtual processor load of a secure container meets the set high load conditions, the scheduling weight of the secure container can be reduced to obtain the target scheduling weight of the secure container. The target scheduling weight is less than the initial scheduling weight of the secure container, and also less than the scheduling weights of other containers deployed on the same host machine.

[0099] The target scheduling weight can be preset. The target scheduling weight is less than the scheduling weights of other containers deployed on the host machine. This allows the scheduling weight of the secure container to be set to the preset target scheduling weight when the virtual processor load of the secure container meets the set high load conditions. The target scheduling weight is less than the initial scheduling weight of the secure container.

[0100] Alternatively, if the virtual processor load of the secure container meets a set high load condition, the scheduling weight of the secure container can be reduced by a set gradient to obtain the target scheduling weight. That is, if the virtual processor load of the secure container meets a set high load condition, the current scheduling weight of the secure container is subtracted from the set gradient to obtain the target scheduling weight. For example, assuming the gradient is set to 0.05, the current scheduling weight of the secure container is subtracted by 0.5 to obtain the target scheduling weight.

[0101] Furthermore, based on the target scheduling weight of the secure container and the scheduling weights of other containers deployed on the host machine, the duration (defined as the third duration) for the secure container to use physical processors in the current scheduling period k can be determined. Specifically, after calculating the ratio P of the target scheduling weight to the sum of the scheduling weights of all containers deployed on the host machine, the product of the ratio P and the scheduling period is calculated to obtain the third duration for the secure container to use physical processors in the current scheduling period k.

[0102] Furthermore, if the third duration is less than or equal to the restricted usage duration corresponding to the secure container (e.g., cpu.quota), then the total time the secure container can use physical processors in the current scheduling period k is determined to be the restricted usage duration. Therefore, the restricted usage duration can be allocated to the target number of virtual processor cores. In this way, the target number of virtual processor cores of the secure container can execute the task in the current scheduling period k within the restricted usage duration.

[0103] Accordingly, if the third duration exceeds the limited usage duration (e.g., cpu.quota) of the secure container, the second duration for which the secure container can exceed the physical processor limit in the current scheduling period k can be determined based on the difference between the third duration and the limited usage duration (e.g., cpu.quota). This approach balances the dynamic scheduling weight adjustment of secure containers, prioritizing the fulfillment of processor quotas for other containers, reducing processor resource conflicts between secure containers and other containers, and thus minimizing interference from elastic processor bandwidth control technology on neighboring containers. Furthermore, it allows for the continued use of elastic processor bandwidth control technology within secure containers, enabling them to exceed the limited usage duration (i.e., processor quota) of the secure container, thereby improving the service quality of secure containers.

[0104] In some embodiments, the difference between the third duration and the restricted usage duration (e.g., cpu.quota) corresponding to the secure container can be used as the second duration during which the secure container can exceed the physical processor usage limit in the current scheduling period k.

[0105] In other embodiments, the product of the virtual processor core expansion factor and the restricted usage time corresponding to the secure container can be calculated as the total time the secure container can use physical processors in the current scheduling period k. Here, the expansion factor equals the target number divided by a first number. Then, the difference between the total time the secure container can use physical processors in the current scheduling period k and the restricted usage time corresponding to the secure container can be calculated. For ease of description and distinction, the difference between the total time the secure container can use physical processors in the current scheduling period k and the restricted usage time (Quota) corresponding to the secure container is defined as the first difference, and the difference between the third time and the restricted usage time (e.g., cpu.quota) corresponding to the secure container is defined as the second difference. Further, the minimum value between the first and second differences can be selected as the second time the secure container can exceed the physical processor usage limit in the current scheduling period k. The smaller of the two values—the first difference between the total time a secure container can use physical processors in the current scheduling period k and the corresponding limit usage time (Quota) of the secure container, and the second difference between the third value and the limit usage time (Quota)—is chosen as the second value. This balances the difference between the time a secure container can exceed its physical processor usage limit, determined by the dynamic scheduling weight of the secure container, and the time a secure container can exceed its physical processor usage limit, determined by the product of the expansion factor and the limit usage time (Quota). Choosing the minimum of the two values ​​ensures that the time a secure container exceeds its physical processor usage limit is still limited, thus preventing excessive resource consumption.

[0106] After determining the second duration for which a secure container can exceed its physical processor usage limit during the current scheduling period k, the second duration can be obtained from the first duration and added to the secure container's corresponding limited usage duration to obtain the target duration. Furthermore, the target duration can be allocated to a target number of virtual processor cores. This allows the target number of virtual processor cores to use the physical processor to execute tasks during the current scheduling period k within their allocated time, achieving elastic processor bandwidth control for the secure container. This enables the secure container to exceed its processor quota limitations, helping to improve the quality of service (QoS) of the secure container under sudden processor load surges.

[0107] In practical applications, secure containers sometimes need to obtain processor information to perform certain operations. For example, a secure container may need to obtain the number of virtual processor cores for resource initialization. In some embodiments, when a process within the container starts, it can read the kernel interface or system scheduling interface to perform resource initialization. The kernel interface can be the / proc / cpuinfo interface or the / proc / stat interface. The system call interface can be the / sys / devices / system / cpu / online interface, the / sys / devices / system / cpu / offline interface, the / sys / devices / system / cpu / possible interface, or the / sys / devices / system / cpu / present interface, etc.

[0108] ` / proc / cpuinfo` is part of the ` / proc` filesystem in an operating system (such as Linux), providing a mechanism to access kernel information about the processor. By reading the ` / proc / cpuinfo` file, detailed information about the processors installed in the system can be obtained. Therefore, applications within a container can read the ` / proc / cpuinfo` kernel interface to obtain processor information in order to initialize a thread pool based on the number of available virtual processor cores (such as the number of CPU cores). ` / proc / stat` contains data about various statistics in the system, including processor (such as CPU) statistics.

[0109] ` / sys / devices / system / cpu / online` is used to set or view which virtual processor cores (such as CPU cores) are currently online in the system. ` / sys / devices / system / cpu / offline` is used to set or view which virtual processor cores (such as CPU cores) are currently offline in the system. ` / sys / devices / system / cpu / possible` displays the range of all potentially usable virtual processor cores (such as CPU cores) in the system. ` / sys / devices / system / cpu / present` displays the range of virtual processor cores (such as CPU cores) actually present in the system.

[0110] Because the number of virtual processor cores in the secure container is expanded in this embodiment, when providing processor information to the secure container, it is necessary to hide the additional (target number - first number) virtual processor cores. This is mainly because the number of virtual processor cores perceived by the user-space application within the secure container is consistent with the secure container's processor quota (cpu.quota), thereby avoiding confusion and inconsistency in resource management. The user-space application initializes and allocates resources based on the visible number of virtual processor cores. If the number of virtual processor cores perceived by the user-space application is inconsistent with the secure container's processor quota (cpu.quota), it may lead to resource management chaos. By hiding the additional expanded virtual processor cores, it can be ensured that the number of virtual processor cores visible from the container's perspective is in a one-to-one relationship with the secure container's processor quota (cpu.quota), thereby simplifying resource management.

[0111] Based on this, in some embodiments of this disclosure, in response to a secure container's access operation to processor information, a resource view of a first number of virtual processor cores can be provided to the secure container. The secure container's access operation to processor information can be implemented as a read operation on the aforementioned kernel interface or system call interface.

[0112] As shown in Figure 3, for ease of description and distinction, vCPU represents a virtual processor core. The vCPU visible from the perspective of the secure container is denoted as gvCPU, and the actual vCPU of the secure container is denoted as hvCPU. The resource request and resource limit in the container creation request in Figure 3 determine the number of virtual processor cores (vCPUs) to be 4, i.e., the first quantity equals 4. The expansion multiplier is 2, meaning the actual number of virtual processor cores (target quantity) created in the secure container is 8, as shown in hvCPU0-7 in Figure 3. Since the additional virtual processor cores are mostly used to handle bursty applications within the secure container, these additional virtual processor cores can be called burstable virtual processor cores, as shown in burstable vCPUs in Figure 3. The "bursting vCPU creation mechanism" in Figure 3 refers to the secure container creation process provided by the aforementioned container creation method. In Figure 3, the number of virtual processor cores visible from the application's perspective within the secure container is 4, i.e., gvCPU0-3 in Figure 3.

[0113] To implement the hiding mechanism of the extended virtual processor cores, in some embodiments of this disclosure, as shown in Figure 3, the actual number of virtual processor cores within the secure container (i.e., the target number) is scaled by an expansion factor to obtain the number of virtual processor cores visible from the secure container's perspective (i.e., the first number). For ease of description, the expansion factor is denoted as f; the actual number of virtual processor cores within the secure container (i.e., the target number) is denoted as s; and the number of virtual processor cores visible from the secure container's perspective (i.e., the first number) is denoted as s'. Then, s' = s / f. In Figure 3, s' = 4, s = 8, and f = 2.

[0114] Specifically, as shown in Figure 4, the kernel of the virtual machine's operating system (Guest OS kernel) can use a bitmap to mark whether virtual processor cores are online or offline. Each bit in the bitmap corresponds to a virtual processor core, with 1 representing that the virtual processor core is online and 0 representing that the virtual processor core corresponding to that bit is offline. Alternatively, 0 represents that the virtual processor core is online and 1 represents that the virtual processor core corresponding to that bit is offline, etc. As shown in Figure 4, hiding multiple extended virtual processor cores can be achieved by retaining the bits [0, s') in the bitmap and clearing the bits [s', s), thereby ensuring that the number of virtual processor cores visible from the perspective of the secure container is the initial number.

[0115] Based on this, in response to the secure container's access to processor information, the first bit map corresponding to the target number of virtual processor cores can be determined. The first bit map is shown in Figure 4(a). One bit in the first bit map corresponds to one virtual processor core; in Figure 4, a bit value of 1 indicates that the bit corresponds to a virtual processor core, and a bit value of 0 indicates that the bit does not correspond to a virtual processor core. Further, the first bit map can be modified into a second bit map according to the expansion factor; the number of target bits in the second bit map is equal to the first number; the target bits refer to the bits that represent the corresponding virtual processor cores. The second bit map is shown in Figure 4(b), where bits with a value of 1 represent target bits. Further, the second bit map can be provided to the secure container, thus providing the secure container with a resource view of the first number of virtual processor cores. Once a secure container is aware of the first number of virtual processor cores, it can perform resource management based on this number. This hides any additional virtual processor cores that are added, ensuring that the number of virtual processor cores visible from the container's perspective is in a one-to-one relationship with the secure container's processor quota (cpu.quota), thus avoiding confusion and inconsistency in resource management.

[0116] To ensure isolation between different applications, they can be bound to different virtual processor cores to avoid resource contention. When an application is bound to a virtual processor core (i.e., gvCPU) in a secure container perspective, the application actually runs on the aforementioned multiplier (i.e., f) of hvCPUs, thus making full use of processor resources.

[0117] The Burst vCPU mapping mechanism works by mapping f high-level vCPUs (hvCPUs) to one high-level vCPU (gvCPU). When an application or service is bound to a gvCPU, it can actually run on all f hvCPUs, thus fully utilizing CPU resources; and this process is transparent to the application or service. The mapping relationship is calculated using the following formula:

[0118] In equation (5), i represents the i-th gvCPU, which is the i-th virtual processor core visible from the container's perspective. Assuming the total number of hvCPUs (i.e. the target number) s is 8 and the expansion factor is 2, then gvCPU0 = hvCPU0 + hvCPU4.

[0119] Specifically, a bitmap can be used to maintain the core binding information of an application. A bit set to 1 indicates that the application can run on the virtual processor core corresponding to that bit, while a bit set to 0 indicates that the application cannot run on the virtual processor core corresponding to that bit. When an application sets its core binding information, the bursty vCPU mapping mechanism can distribute and bind the application to f (i.e., the expansion multiple) hvCPUs according to the relationship in the above formula; when the application reads the core binding information, the bursty vCPU mapping mechanism aggregates the f hvCPUs into a single gvCPU according to the relationship in the above formula.

[0120] Based on the aforementioned bursty vCPU mapping mechanism, in response to processor binding operations by secure containers, the target virtual processor core and the process to be bound can be obtained. The secure container can perform processor binding operations by reading kernel interfaces or system call interfaces. Kernel interfaces can be ` / sys / fs / cgroup / cpuset / cpuset.cpus` or ` / sys / fs / cgroup / cpuset / cpuset.effective_cpus`, etc. System call interfaces can be `sched_setaffinity` or `sched_getaffinity`, etc.

[0121] The ` / sys / fs / cgroup / cpuset / cpuset.cpus` directive specifies a set of processor cores (e.g., CPU cores) that can be used by processes within a resource control group (Cgroup). The ` / sys / fs / cgroup / cpuset / cpuset.effective_cpus` directive displays the set of processor cores (e.g., CPU cores) that are actually available to processes within the current resource control group (Cgroup).

[0122] `sched_setaffinity` is a system call used to set the processor (such as CPU) affinity of a process. This means it can specify which processor cores (such as CPU cores) a process can only run on. `ched_getaffinity` is a system call used to retrieve the current processor (such as CPU) affinity setting of a process.

[0123] Furthermore, based on the expansion factor f, the target bits corresponding to the target virtual processor core in the aforementioned first-order diagram can be determined as f (i.e., the expansion factor). The target bits corresponding to the target virtual processor core in the aforementioned first-order diagram can be determined according to the aforementioned formula (1). As shown in Figure 5, the target bits corresponding to gvCPU0 in the aforementioned first-order diagram are the bits corresponding to hvCPU0 and hvCPU4. Furthermore, the process to be bound can be bound to the virtual processor core corresponding to the determined f expansion factor bits, thus allowing the process to be bound to run on the expansion factor (i.e., f) virtual processor cores, fully utilizing processor resources and improving processor resource utilization.

[0124] The aforementioned embodiments provide a mechanism for hiding and mapping multiple extended virtual processor cores. This mechanism hides the multiple extended virtual processor cores created to support elastic processor bandwidth control technology and appropriately maps the virtual processor cores visible from the container's perspective to the multiple extended virtual processor cores. This makes the multiple extended virtual processor cores transparent to applications within the secure container, requiring no modification costs for the applications within the secure container.

[0125] It is worth noting that the secure container provided in this disclosure can run various services, such as database services, online shopping services, video services, or cloud computing services, but is not limited to these. The inventors of this disclosure apply the secure container provided in this disclosure to a database, create a secure container corresponding to the database using the container creation method provided in this disclosure, schedule resources for the secure container corresponding to the database using the processor time scheduling method provided in this disclosure, and evaluate the database performance using the Transaction Processing Performance Council Benchmark H (TPC-H). TPC-H is a widely used benchmark for evaluating the performance of database systems. The TPC-H benchmark covers a variety of complex query patterns and aims to simulate real-world data analysis and reporting tasks.

[0126] The main metrics of TPC-H include: (1) Duration, which is the total time required to complete all queries in the TPC-H benchmark test. The lower the Duration, the better. The lower the Duration, the faster the system completes all queries and the higher the performance. (2) Throughput, which is the amount of work that the system can complete per unit of time, usually the number of queries completed per hour. The higher the Throughput, the better. The higher the Throughput, the more queries the system can process per unit of time and the stronger the performance.

[0127] Test results show that, with the database configuration unchanged, the secure container corresponding to the database created using the container creation method provided in this embodiment of the disclosure, and the processor time scheduling method provided in this embodiment of the disclosure for resource scheduling of the secure container corresponding to the database, reduces the TPC-H duration index of the database by 32% and increases the throughput index by 45%.

[0128] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 201 and 202 can be device A; or the execution subject of step 201 can be device A, and the execution subject of step 202 can be device B; and so on.

[0129] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 201, 202, etc., are merely used to distinguish different operations and do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0130] Accordingly, embodiments of this disclosure also provide a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause one or more processors to perform the steps in the container creation method and / or processor time scheduling method described above.

[0131] This disclosure also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps in the container creation method and / or processor time scheduling method described above. In this disclosure, the specific implementation of the computer program product is not limited. In some embodiments, the computer program product may be implemented as an application (APP), a mini-program, a PC-side client, a program module, a plug-in, an installation package, a software development kit (SDK), an optical disc image file (such as an ISO file), a plug-in, or software in the form of Software as a Service (SaaS), etc., but is not limited thereto.

[0132] Figure 6 is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. As shown in Figure 6, the electronic device includes a memory 60a and a processor 60b. The memory 60a is used to store computer programs.

[0133] Processor 60b is coupled to memory 60a and is used to execute computer programs to perform steps in the container creation method and / or processor time scheduling method provided in the foregoing embodiments. Specific implementation details of each step can be found in the relevant descriptions of the foregoing embodiments, and will not be repeated here.

[0134] In some alternative embodiments, as shown in FIG6, the electronic device may further include optional components such as a communication component 60c, a power supply component 60d, a display component 60e, and an audio component 60f. FIG6 only schematically shows some components and does not mean that the electronic device must include all the components shown in FIG6, nor does it mean that the electronic device can only include the components shown in FIG6.

[0135] Furthermore, the components within the dashed boxes in Figure 6 are optional, not mandatory, and their specific requirements depend on the product form of the electronic device. The electronic device in this embodiment can be a desktop computer, laptop computer, mobile phone, or IoT device; it can also be a traditional server, cloud server, or server cluster, or other server equipment.

[0136] In embodiments of this disclosure, the memory is used to store computer programs and can be configured to store various other data to support operation on its host device. The processor can execute the computer programs stored in the memory to implement corresponding control logic. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Electrically Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0137] In this embodiment of the disclosure, the processor can be any hardware processing device capable of executing the above-described method logic. Optionally, the processor can be a central processing unit (CPU), a graphics processing unit (GPU), or a microcontroller unit (MCU); it can also be a programmable device such as a field-programmable gate array (FPGA), a programmable array logic (PAL), a general array logic (GAL), or a complex programmable logic device (CPLD); or it can be an advanced RISC machine (ARM) or a system on chip (SoC), etc., but is not limited thereto.

[0138] In embodiments of this disclosure, the communication component is configured to facilitate wired or wireless communication between its host device and other devices. The device housing the communication component can access wireless networks based on communication standards, such as Wireless Fidelity (WiFi), 2G or 3G, 4G, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In another exemplary embodiment, the communication component may also be implemented based on Near Field Communication (NFC), Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), or other technologies.

[0139] In embodiments of this disclosure, the display component may include a liquid crystal display (LCD) and a touch panel (TP). If the display component includes a touch panel, the display component may be implemented as a touchscreen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0140] In embodiments of this disclosure, a power supply component is configured to provide power to various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component resides.

[0141] In embodiments of this disclosure, the audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals. For example, in devices with voice interaction capabilities, voice interaction with a user can be achieved through the audio component.

[0142] It should be noted that the terms "first" and "second" in this article are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0143] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0144] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0145] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0146] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0147] In a typical configuration, a computing device includes one or more processors (CPU, etc.), input / output interfaces, network interfaces, and memory.

[0148] Memory may include non-persistent storage in computer-readable media, such as random-access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0149] Computer storage media are readable storage media, also known as removable media. Removable and non-removable media can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient media, such as modulated data signals and carrier waves.

[0150] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the aforementioned element.

[0151] The above description is merely an embodiment of this disclosure and is not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.

Claims

1. A processor time scheduling method, wherein, include: When the load on the virtual processor of the secure container meets the high load condition, obtain the first unused duration accumulated by the virtual processor of the secure container in the historical scheduling cycle; the virtual processor has a target number of virtual processor cores; The target quantity is obtained by extending the first quantity; the first quantity is determined based on the resource request amount and resource limit amount of the security container; The first duration is consumed by the target number of virtual processor cores to execute tasks using physical processors.

2. The method according to claim 1, wherein, The step of using the target number of virtual processor cores to consume the first duration to execute tasks using physical processors includes: For the current scheduling period, obtain the second duration from the first duration during which the secure container can exceed the limit of physical processor use in the current scheduling period; The target duration is obtained by adding the second duration to the limited usage duration corresponding to the secure container; the limited usage duration refers to the upper limit of the time the secure container uses the physical processor. The target number of virtual processor cores are allocated the target duration of time so that the target number of virtual processor cores can use the physical processor to execute tasks of the current scheduling cycle within the allocated time.

3. The method according to claim 2, wherein, The step of obtaining the second duration from the first duration during which the secure container can exceed the physical processor limit in the current scheduling cycle includes: The product of the expansion factor and the limited usage time is calculated as the total time that the virtual processor can use the physical processor in the current scheduling cycle; the expansion factor is equal to the target number divided by the first number; Calculate the first difference between the total duration and the restricted usage duration, and use it as the second duration, and obtain the second duration from the first duration.

4. The method according to claim 2 or 3, wherein, The host machine where the secure container resides has other containers deployed on it, and the secure container shares the physical processor with the other containers; the method further includes: If the load on the virtual processor of the secure container meets the set high load condition, reduce the scheduling weight of the secure container to obtain the target scheduling weight of the secure container. Based on the scheduling weights of the other containers and the target scheduling weight of the secure container, the third duration for which the secure container uses the physical processor in the current scheduling cycle is determined; the target scheduling weight is less than the scheduling weights of the other containers. If the third duration is greater than the restricted usage duration corresponding to the safety container, then the second duration is determined based on the second difference between the third duration and the restricted usage duration.

5. The method according to claim 4, wherein, The method further includes: The product of the expansion factor and the limited usage time is calculated as the total time that the secure container can use the physical processor in the current scheduling cycle; the expansion factor is equal to the target number divided by the first number; Calculate the first difference between the total duration and the restricted usage duration; Determining the second duration based on the second difference between the third duration and the restricted usage duration includes: The minimum value between the first difference and the second difference is selected as the second duration.

6. The method according to any one of claims 2-5, wherein, The time allocated to the target number of virtual processor cores for the target duration includes: With the constraint that the sum of the time allocated to the target number of virtual processor cores equals the target duration, the time to be allocated for each of the target number of virtual processor cores is determined according to the resource requirements of the tasks executed by each virtual processor core in the current scheduling cycle. Each virtual processor core is allocated a corresponding time period to be allocated, thereby allocating a target time period to the target number of virtual processor cores.

7. The method according to any one of claims 1-6, wherein, The method further includes: For the previous scheduling period of the current scheduling period, if the total time consumed by the target number of virtual processor cores to complete the task in the previous scheduling period reaches the limited usage time corresponding to the secure container, then it is determined that the load of the virtual processors of the secure container meets the set high load condition.

8. The method according to any one of claims 1-7, wherein, The method further includes: Obtain a container creation request, the container creation request being used to request the creation of the secure container, the container creation request including the resource request amount and the resource limit amount; The number of virtual processor cores of the virtual processor is determined based on the resource request amount and the resource limit amount, and is used as the first quantity; The first quantity is expanded to obtain the target quantity; Based on the target number of virtual processor cores, a virtual machine instance is created on the host machine; and the security container is created on the virtual machine instance so that the virtual processor of the security container has the target number of virtual processor cores.

9. The method according to claim 8, wherein, The container creation request also includes: an expansion factor; the expansion factor is greater than 1; Expanding the first quantity to obtain the target quantity includes: The first quantity is expanded according to the expansion factor to obtain the target quantity.

10. The method according to claim 8, wherein, Also includes: In response to the secure container's access operation to processor information, a resource view of the first number of virtual processor cores is provided to the secure container.

11. The method according to claim 10, wherein, The step of providing the secure container with a resource view of the first number of virtual processor cores in response to the secure container's access operation to processor information includes: In response to the secure container's access operation to processor information, a first bit map corresponding to the target number of virtual processor cores is determined; one bit of the first bit map corresponds to one virtual processor core. Based on the expansion factor, the first bitmap is modified into a second bitmap; the number of target bits in the second bitmap is equal to the first number; the target bit refers to the bit that represents the corresponding virtual processor core; the expansion factor is equal to the target number divided by the first number; The second bitmap is provided to the secure container to provide the secure container with a resource view of the first number of virtual processor cores.

12. The method according to claim 11, wherein, Also includes: In response to the processor binding operation of the secure container, the target virtual processor core and the process to be bound in the processor binding operation are obtained; Based on the expansion factor, determine the target bit position corresponding to the target virtual processor core in the first bit diagram, which corresponds to the expansion factor bit position. Bind the process to be bound to the virtual processor core corresponding to the multiplied number of bits.

13. The method according to any one of claims 8-12, characterized in that, Also includes: After creating the secure container, enable the elastic processor bandwidth control technology in the secure container; wherein enabling the elastic processor bandwidth control technology includes adding specific command-line parameters to the configuration file of the secure container to instruct the client operating system to start the elastic processor bandwidth control function.

14. The method according to any one of claims 1-6, characterized in that, Also includes: Monitor the processor utilization of the secure container; if the processor utilization is greater than or equal to a set utilization threshold, determine that the load of the virtual processor of the secure container meets the set high load condition.

15. A method for creating a container, wherein, include: Obtain a container creation request, which is used to request the creation of a secure container, and the container creation request includes the resource request amount and the resource limit amount; The number of virtual processor cores of the security container is determined based on the resource request amount and the resource limit amount, and is used as the first quantity; The first quantity is expanded to obtain the target quantity; Based on the target number of virtual processor cores, create virtual machine instances on the host machine; The secure container is created on the virtual machine instance to perform tasks using the target number of virtual processor cores, consuming the previously accumulated unused processor time of the secure container, when the virtual processor load of the secure container meets high load conditions.

16. The method according to claim 15, characterized in that, Also includes: Pre-configure the scheduling weights of each container deployed on the host machine; If the virtual processor load of the secure container meets the set high load condition, reduce the scheduling weight of the secure container to obtain the target scheduling weight of the secure container. Based on the target scheduling weight and the scheduling weights of the other containers, adjust the time allocation ratio of the physical processor used by the secure container in the current scheduling cycle.

17. The method according to claim 15, characterized in that, Also includes: In response to the secure container's read operation on the kernel interface or system call interface, the number of additional virtual processor cores is hidden, so that the number of virtual processor cores visible from the secure container's perspective remains consistent with the secure container's processor quota.

18. An electronic device, wherein, include: A memory and a processor; wherein the memory is used to store computer programs; The processor is coupled to the memory for executing the computer program to perform the steps of the method according to any one of claims 1-17.

19. A computer-readable storage medium storing computer instructions, wherein, When the computer instructions are executed by one or more processors, the one or more processors are caused to perform the steps of the method according to any one of claims 1-17.

20. A computer program product, wherein, Includes a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps of the method according to any one of claims 1-17.

Images