Container instance creation method and apparatus, electronic device, and storage medium

Abstract

The application provides a container instance creation method and device, electronic equipment and storage medium, comprising: intercepting an instance creation request issued by a container runtime component for a target container instance, and obtaining computing resource requirement information of the target container instance from the instance creation request; in response to intercepting the instance creation request, obtaining physical hardware topology information of a host node where the target container instance is located; generating a physical binding strategy according to the computing resource requirement information and the physical hardware topology information; injecting the physical binding strategy into runtime configuration information of the target container instance, and starting the target container instance according to the injected runtime configuration information, so that virtual processor threads of the target container instance are forced to be locked on the physical processor core, and the memory of the target container instance is forced to be allocated in the non-uniform memory access node.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a method, apparatus, electronic device and storage medium for creating container instances. Background Technology

[0002] With the popularization of cloud-native technologies, container instances are evolving from traditional stateless web services to high-performance, latency-sensitive core services (such as high-frequency quantitative trading, real-time inference of large models, and 5G edge core networks). In these scenarios, users have extremely high requirements for the exclusivity of computing resources and the determinism of performance. To meet the needs of multi-tenant isolation and security, cloud platforms generally adopt secure containers based on lightweight virtual machine technology as the runtime environment for container instances. At the same time, to improve resource utilization and memory access performance, modern servers generally adopt a non-uniform memory access (NUMA) architecture.

[0003] To address the resource isolation requirements of the aforementioned high-performance container instances, the existing technology adopts the following solution: In the container orchestration platform, a fixed set of CPU cores is allocated to the container group when it is created through the static policies of the topology manager and the central processing unit (CPU) manager provided by the node agent component, and all processes in the container group are restricted to run on the allocated set of CPU cores through the control group (Cgroup) mechanism at the operating system level.

[0004] However, when using the existing solutions described above, the virtual CPU threads inside the secure container instance will still drift between the allocated physical cores, resulting in memory access across NUMA nodes, which leads to increased memory access latency and performance jitter. Summary of the Invention

[0005] This application provides a container instance creation method, apparatus, electronic device, and storage medium to solve the problem in the prior art that the virtual CPU threads inside a secure container instance still drift between allocated physical cores, resulting in cross-NUMA node memory access, which leads to increased memory access latency and performance jitter.

[0006] Firstly, this application provides a method for creating container instances, applied to extended components deployed on host nodes, including: Intercept the instance creation request issued by the container runtime component for the target container instance, and obtain the computing resource requirement information of the target container instance from the instance creation request; In response to intercepting the instance creation request, obtain the physical hardware topology information of the host node where the target container instance is located; Based on the computing resource requirement information and the physical hardware topology information, a physical binding strategy is generated, wherein the physical binding strategy is used to indicate that: the virtual processor thread of the target container instance is bound one-to-one with the physical processor core of the host node, and the memory allocation domain of the target container instance and the bound physical processor core belong to the same non-uniform memory access node. The physical binding strategy is injected into the runtime configuration information of the target container instance, and the target container instance is started according to the injected runtime configuration information, so that the virtual processor thread of the target container instance is forcibly locked to the physical processor core, and the memory of the target container instance is forcibly allocated within the non-uniform memory access node.

[0007] In one possible implementation, prior to the interception of the instance creation request issued by the container runtime component for the target container instance, the method further includes: Establish a communication channel between the host node and the container runtime component; A registration request is sent to the container runtime component through the communication channel. The registration request is used to declare the types of lifecycle events that need to be intercepted. When the container runtime component triggers the sandbox creation event according to the registration request, it receives the sandbox instance creation request sent by the container runtime component through the communication channel, and extracts the service quality identifier of the target container instance from the sandbox instance creation request; When it is determined, based on the quality of service identifier, that the target container instance needs to perform hardware topology alignment, the step of intercepting the instance creation request issued by the container runtime component for the target container instance is executed.

[0008] In one possible implementation, generating a physical binding strategy based on the computing resource requirement information and the physical hardware topology information includes: Based on the physical hardware topology information, determine the node identifier of each non-unified memory access node included in the host node, as well as the core identifier and idle status of the physical processor core under each non-unified memory access node. Based on the number of core requirements indicated by the computing resource requirement information, a target non-uniform memory access node is selected from non-uniform memory access nodes whose number of idle physical processor cores is greater than or equal to the number of core requirements, and a set of target physical processor cores matching the number of core requirements is selected from the idle physical processor cores under the target non-uniform memory access node. A processor core binding mask is generated based on the core identifier of the target physical processor core, a memory node binding mask is generated based on the node identifier of the target non-uniform memory access node, and the processor core binding mask and the memory node binding mask are combined into the physical binding strategy.

[0009] In one possible implementation, injecting the physical binding policy into the runtime configuration information of the target container instance includes: Obtain the initial configuration information generated by the container runtime component for the target container instance, the initial configuration information including resource limit fields and extended annotation fields; Write the processor core binding mask in the physical binding policy into the processor core binding configuration item in the resource limit field, and write the memory node binding mask in the physical binding policy into the memory node binding configuration item in the resource limit field; The control instructions used to instruct the virtual machine pad to perform processor core binding are written into the extended annotation field to obtain the injected runtime configuration information, and the injected runtime configuration information is returned to the container runtime component to replace the initial configuration information.

[0010] In one possible implementation, the method further includes: Obtain the process identifier of the virtual machine monitor process corresponding to the target container instance; Based on the process identifier, a target thread belonging to the virtual processor type is identified from the thread space of the virtual machine monitor process; The thread affinity setting interface provided by the operating system of the host node is invoked to forcibly bind the target thread to the physical processor core indicated by the physical binding policy.

[0011] In one possible implementation, after starting the target container instance based on the injected runtime configuration information, the method further includes: When any physical processor core on the host node is detected to be offline, the target container instance bound to the first physical processor core where the offline event occurred is identified from the locally stored topology mapping record. Within the non-unified memory access node to which the first physical processor core belongs, a second physical processor core that is in an idle state is selected, and an updated physical binding strategy is generated based on the core identifier of the second physical processor core and the node identifier of the non-unified memory access node. Call the container resource update interface provided by the container runtime component to update the processor core binding configuration item in the runtime configuration information of the target container instance to the core identifier of the second physical processor core; The thread affinity setting interface provided by the operating system of the host node is invoked to forcibly migrate and bind the virtual processor thread of the target container instance to the second physical processor core.

[0012] In one possible implementation, the extension component is a plugin based on the node resource interface standard; The interception of instance creation requests issued by the container runtime component against the target container instance includes: Establish a communication connection between the plugin and the container runtime component; When the container runtime component triggers a lifecycle hook, the plugin intercepts the instance creation request issued by the container runtime component for the target container instance based on the communication connection.

[0013] Secondly, this application provides a container instance creation apparatus, comprising: The interception module is used to intercept instance creation requests issued by the container runtime component for the target container instance, and to obtain the computing resource requirement information of the target container instance from the instance creation request. The acquisition module is used to acquire the physical hardware topology information of the host node where the target container instance is located in response to the interception of the instance creation request; The generation module is used to generate a physical binding strategy based on the computing resource requirement information and the physical hardware topology information. The physical binding strategy is used to indicate that the virtual processor thread of the target container instance is bound to the physical processor core of the host node in a one-to-one manner, and that the memory allocation domain of the target container instance and the bound physical processor core belong to the same non-uniform memory access node. The injection module is used to inject the physical binding strategy into the runtime configuration information of the target container instance, and start the target container instance according to the injected runtime configuration information, so that the virtual processor thread of the target container instance is forcibly locked to the physical processor core, and the memory of the target container instance is forcibly allocated within the non-uniform memory access node.

[0014] Thirdly, this application provides an electronic device, including: a processor and a memory, wherein the processor is configured to execute a container instance creation program stored in the memory to implement the container instance creation method described in any one of the first aspects.

[0015] Fourthly, this application provides a storage medium storing one or more programs that can be executed by one or more processors to implement the container instance creation method described in any one aspect.

[0016] Compared with the prior art, the technical solution provided in this application has the following advantages: The method provided in this application intercepts and obtains the computing resource requirements of the target container instance indicated in the instance creation request when the container runtime component initiates the instance creation request, and obtains the physical hardware topology information of the host node where the target container instance resides. Then, it generates a physical binding strategy based on the computing resource requirements and physical hardware topology information. This strategy is used to bind the virtual processor thread of the target container instance to the physical processor core of the host node one-to-one, and ensures that the memory allocation domain of the target container instance and the bound physical processor core belong to the same non-uniform memory access node. Finally, the physical binding strategy is injected into the runtime configuration information of the target container instance, and the target container instance is started according to the injected runtime configuration information. Thus, a resource binding relationship that penetrates the virtual machine boundary is established for the container instance during the startup phase, fundamentally avoiding the drift of virtual processor threads between physical processor cores. Simultaneously, it ensures that the memory allocation domain and the virtual processor thread are located within the same non-uniform memory access node, eliminating the latency overhead caused by cross-node memory access. Ultimately, it effectively suppresses performance jitter and meets the requirements of deterministic computing resources and low latency for high-performance business scenarios. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0019] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0020] Figure 1 A flowchart illustrating an embodiment of a container instance creation method provided in this application; Figure 2A flowchart illustrating an embodiment of another container instance creation method provided in this application; Figure 3 A flowchart illustrating another embodiment of the container instance creation method provided in this application; Figure 4 A flowchart illustrating an embodiment of another container instance creation method provided in this application; Figure 5 An interactive flowchart of a container instance creation method provided in an embodiment of this application; Figure 6 A block diagram illustrating an embodiment of a container instance creation apparatus provided in this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0023] To address the technical issue in existing technologies where virtual CPU threads within secure container instances still drift between allocated physical cores, leading to cross-NUMA node memory access and increased memory access latency and performance jitter, this application provides a container instance creation method. This method establishes resource binding relationships that penetrate virtual machine boundaries during the container instance startup phase, fundamentally preventing the drift of virtual processor threads between physical processor cores. Simultaneously, it ensures that the memory allocation domain and virtual processor threads reside within the same non-uniform memory access node, eliminating the latency overhead caused by cross-node memory access. Ultimately, this effectively suppresses performance jitter and meets the requirements of deterministic computing resources and low latency in high-performance business scenarios.

[0024] Figure 1This is a flowchart illustrating an embodiment of a container instance creation method provided in this application. In one embodiment, the method is applied to an extended component deployed on a host node. Figure 1 As shown, the method includes the following steps: Step 101: Intercept the instance creation request issued by the container runtime component for the target container instance, and obtain the computing resource requirement information of the target container instance from the instance creation request.

[0025] Container runtime component: refers to the underlying service component deployed on the host node, responsible for managing the complete lifecycle of containers (including container pulling, creation, startup, stopping, and destruction). In this embodiment, the container runtime component can specifically be Containerd or CRI-O. Such components conform to the OCI (Open Container Initiative) specification and provide standardized container management interfaces.

[0026] Target container instance: In a serverless cloud-native architecture, this refers to the smallest computing delivery unit provided to the user, where the user does not need to be aware of the configuration of the underlying physical server or node operating system. In this embodiment, the target container instance specifically refers to a secure container (such as Kata Containers) implemented based on lightweight virtual machine technology. This type of container allocates an independent guest operating system kernel and hardware virtualization boundary to each container group to achieve strong isolation and high security.

[0027] Instance creation request: This refers to the creation operation request initiated by the container runtime component to the underlying layer in order to launch the target container instance after receiving the scheduling instruction from the upper-layer orchestration system (such as Kubernetes). In this embodiment, the instance creation request is specifically a request triggered by the container runtime component at a critical node in the container instance lifecycle (e.g., after the creation instruction is issued, or during the request suspension period before the isolation environment is established). This request carries configuration information passed through from the upper layer.

[0028] Computing resource requirements: This refers to the resource quota specified by the user or the upper-layer orchestration system for the target container instance, including at least the number of CPU (Central Processing Unit) cores and the amount of memory. For example, if a user requests a high-performance computing container instance with 4 cores and 8GB of memory, the computing resource requirements information indicates that the core requirement is 4 cores.

[0029] In this embodiment, the extended component deployed on the host node interacts with the container runtime component through a pre-established communication channel. When the container runtime component triggers the container instance creation process, it bypasses or requests suspension of the process, thereby intercepting the instance creation request issued by the container runtime component for the target container instance. The extended component can communicate with the container runtime component using a standardized extension framework (such as a plugin implemented using the NRI (Node Resource Interface) standard). This framework allows externally customized compute node plugins to intervene in the control flow at critical nodes in the container lifecycle. After intercepting the instance creation request, the extended component parses the compute resource requirements information of the target container instance (e.g., a core requirement of 4 cores) from the request body of the instance creation request.

[0030] Step 102: In response to the interception of the instance creation request, obtain the physical hardware topology information of the host node where the target container instance is located.

[0031] Physical hardware topology information: refers to the distribution and organization of underlying hardware resources of the host nodes, including at least the number of NUMA (Non-Uniform Memory Access) nodes contained in the host, the memory capacity and usage status of each NUMA node, the core identifier (such as core number 0, 1, 2, 3) of the physical processor cores (i.e. physical CPU cores) under each NUMA node, and the online / idle status of each physical processor core.

[0032] Host node: refers to the physical server or physical host that runs the target container instance. This node has real hardware resources, including multiple physical processor cores, memory, and NUMA architecture. In this embodiment, the host node is the actual running platform for the target container instance, and the extended components are deployed and run on this node.

[0033] In this embodiment, in response to successfully intercepting an instance creation request, the extended component invokes the global topology awareness module on the host node. This module reads a specified directory (e.g., / sys / devices / system / node / ) in the operating system kernel file system to obtain the physical hardware topology information of the current host node in real time. Specifically, the topology awareness module traverses each NUMA node subdirectory (e.g., node0, node1) under this directory to obtain the memory capacity and free memory of each NUMA node, the list of physical processor core numbers under that node, and the online status of each core. For example, the topology awareness module can detect that NUMA Node 0 has free cores 0, 1, 2, and 3 and sufficient memory, while NUMA Node 1 has free cores 4, 5, 6, and 7. This module organizes the above information into structured physical hardware topology information for use in subsequent steps.

[0034] Step 103: Generate a physical binding strategy based on the computing resource requirement information and the physical hardware topology information. The physical binding strategy is used to indicate that the virtual processor thread of the target container instance is bound one-to-one with the physical processor core of the host node, and that the memory allocation domain of the target container instance and the bound physical processor core belong to the same non-uniform memory access node.

[0035] Physical binding strategy: refers to a set of configuration instructions used to guide the host operating system and VMM (Virtual Machine Monitor) in resource binding, including at least processor core binding masks and memory node binding masks. In this embodiment, the core constraint of the physical binding strategy is to forcibly bind the virtual processor thread of the target container instance to the physical processor core of the host node one-to-one, and to ensure that the memory allocation domain of the target container instance and the bound physical processor core belong to the same non-uniform memory access node.

[0036] Virtual processor thread: refers to the host operating system thread corresponding to the vCPU (Virtual Central Processing Unit) simulated by the VMM inside the secure container. In this embodiment, this thread actually carries out the execution of business instructions inside the container, and its scheduling behavior is controlled by the host operating system kernel. By default, it can migrate between multiple physical processor cores.

[0037] Physical processor core: refers to an independent physical execution unit on the host CPU chip, each core capable of independently executing instruction sequences. In this embodiment, the physical processor core is the hardware carrier for the actual execution of virtual processor threads, and each core has a unique core identifier (such as a core number).

[0038] Non-uniform memory access node (NUMA node): In a multiprocessor server hardware architecture, physical memory is divided into multiple memory domains, each directly connected to a different physical CPU chip. In this embodiment, the CPU experiences extremely low latency when accessing the memory of its directly connected local node, while accessing the remote memory of other nodes across the system interconnect bus (such as the QPI / UPI bus) results in significant latency degradation and performance penalties.

[0039] In this embodiment, the extension component performs resource allocation calculations to generate a physical binding strategy based on the computing resource requirement information (e.g., 4 CPU cores required) obtained in step 101 and the physical hardware topology information obtained in step 102. Specifically, the extension component first determines the physical processor cores under each NUMA node and their idle status based on the physical hardware topology information; then, according to a preset resource allocation rule (e.g., prioritizing the allocation of idle physical processor cores that meet the core requirement within the same NUMA node), it selects a set of target physical processor cores that meet the computing resource requirement information and their respective target NUMA nodes from the physical hardware topology information; finally, it generates a processor core binding mask (e.g., cpus="0-3") based on the core identifier of the selected target physical processor cores, generates a memory node binding mask (e.g., mems="0") based on the node identifier of the target NUMA node, and combines the two into a physical binding strategy.

[0040] Step 104: Inject the physical binding policy into the runtime configuration information of the target container instance, and start the target container instance according to the injected runtime configuration information, so that the virtual processor thread of the target container instance is forcibly locked to the physical processor core, and the memory of the target container instance is forcibly allocated within the non-uniform memory access node.

[0041] Runtime configuration information: refers to the standard configuration file (i.e., config.json) conforming to the OCI runtime specification. This file precisely describes the lifecycle management, system resource limits, network, storage, and security configuration instructions required for the container instantiation process in the form of a system configuration trie. In this embodiment, the runtime configuration information includes at least the resource limit field (Linux.Resources, used to set CPU binding and memory binding) and the extended annotation field (Annotations, used to pass custom instructions).

[0042] Injection: This refers to the process by which the extended component writes the generated physical binding policy into the corresponding field of the runtime configuration information of the target container instance, and replaces the original configuration information with the modified configuration information. In this embodiment, the injection operation occurs during the "admission suspension period" before the container instance starts, ensuring that the binding policy takes effect immediately when the instance starts.

[0043] In this embodiment, the extension component first obtains the initial OCI specification configuration (i.e., the initial config.json) generated by the container runtime component for the target container instance. Then, the extension component writes the physical binding policy generated in step 103 into this configuration: specifically, it writes the constraint instructions (such as processor core binding masks, memory node binding masks, etc.) contained in the physical binding policy into the corresponding fields of the runtime configuration information in a format recognizable by the container runtime component and the underlying virtualization component. For example, the binding policy can be written into the corresponding configuration item of the resource limit field, and control instructions used to guide the Kata Shim to perform physical binding can also be written into the extension annotation field, thereby obtaining the injected runtime configuration information. The extension component returns this injected configuration information as a response to the container runtime component to replace the initial configuration. After receiving the response, the container runtime component releases the suspended state and starts the target container instance based on the injected runtime configuration information: the underlying component (such as the virtual machine pad) parses the binding instructions in the configuration and translates them into startup parameters or system calls that the VMM (such as QEMU or Cloud Hypervisor) can recognize. Finally, at the moment the underlying micro virtual machine starts, it forcibly locks the virtual processor thread to the physical processor core specified by the physical binding policy and forcibly allocates memory in the specified NUMA node.

[0044] The technical solution provided in this application intercepts and obtains the computing resource requirements of the target container instance indicated in the instance creation request when the container runtime component initiates the instance creation request, and obtains the physical hardware topology information of the host node where the target container instance is located. Then, a physical binding policy is generated based on the computing resource requirements and physical hardware topology information. This policy instructs the virtual processor threads of the target container instance to be bound one-to-one with the physical processor cores of the host node, and ensures that the memory allocation domain of the target container instance and the bound physical processor core belong to the same non-uniform memory access node. Finally, the physical binding policy is injected into the runtime configuration information of the target container instance, and the target container instance is started according to the injected runtime configuration information. In this way, a resource binding relationship that penetrates the virtual machine boundary is established for the container instance during the startup phase, thereby fundamentally avoiding the drift of virtual processor threads between physical processor cores, while ensuring that the memory allocation domain and the virtual processor threads are located within the same non-uniform memory access node, eliminating the latency overhead caused by cross-node memory access, and ultimately achieving effective suppression of performance jitter, meeting the requirements of deterministic computing resources and low latency for high-performance business scenarios.

[0045] In one embodiment, prior to step 101, the following steps may be included: establishing a communication channel between the host node and the container runtime component; sending a registration request to the container runtime component through the communication channel, the registration request being used to declare the types of lifecycle events to be intercepted; when the container runtime component triggers the sandbox creation event according to the registration request, receiving a sandbox instance creation request sent by the container runtime component through the communication channel, and extracting the service quality identifier of the target container instance from the sandbox instance creation request; when it is determined based on the service quality identifier that the target container instance needs to perform hardware topology alignment, performing the step of intercepting the instance creation request issued by the container runtime component for the target container instance.

[0046] Communication channel: refers to the communication connection established between the extended component and the container runtime component for data interaction. In this embodiment, the communication channel may specifically be a Unix Domain Socket (such as / var / run / nri / nri.sock), which supports the gRPC (gRPC Remote Procedure Call) protocol to enable bidirectional communication between the extended component and the container runtime component.

[0047] Registration Request: This refers to a request message sent by an extended component to the container runtime component to declare the types of lifecycle events it needs to subscribe to. In this embodiment, the registration request is specifically a RegisterPlugin request based on the NRI standard. This request explicitly declares that the extended component needs to subscribe to two core lifecycle hooks: the RunPodSandbox creation event and the CreateContainer event.

[0048] Lifecycle event types: These refer to the various stages of events triggered by the container runtime component throughout the entire process of a container instance's creation and destruction, including at least sandbox creation events and container creation events. In this embodiment, the extended component declares the lifecycle event types that need to be intercepted, informing the container runtime component that it needs to send a request to the extended component when the corresponding event is triggered.

[0049] Sandbox instance creation request: This refers to the creation request triggered by the container runtime component when launching the outer isolation environment (i.e., sandbox) of the secure container. In this embodiment, the sandbox instance creation request is specifically a RunPodSandboxRequest sent synchronously to the extension component via the gRPC protocol before the container runtime component prepares to launch the outer sandbox of the Kata virtual machine. This request is used to intercept and suspend the container instance creation process during the sandbox creation phase.

[0050] Quality of Service (QoS) identifier: This refers to the QoS level label assigned by the user or upper-layer orchestration system to the target container instance, indicating the instance's requirement for performance determinism. In this embodiment, the QoS identifier is carried in the Annotations dictionary of the PodSandboxConfig in the sandbox instance creation request. For example, kci.io / qos-class="extreme-low-latency" indicates an extremely low latency requirement. The extended components parse this identifier to determine whether the current instance needs to perform hardware topology alignment.

[0051] In this embodiment, before step 101, the extended component first performs the following initialization and intent recognition operations: The extended component establishes a gRPC communication connection with the NRI microservice of the container runtime component on the host node through a communication channel, and sends a registration request to declare that it needs to subscribe to the sandbox creation event and the container creation event, and enters the ready listening state. When the underlying physical machine on-site agent receives the container instance creation instruction issued by the cloud and calls the container runtime interface, before the container runtime component prepares to launch the outer sandbox of the Kata virtual machine, it synchronously sends a sandbox instance creation request to the extended component through the gRPC protocol. At this time, the container instance launch process is forcibly suspended. The extended component receives and parses the request, extracts the service quality identifier (SQI) of the target container instance from the request body, and determines whether the current instance needs to perform hardware topology alignment based on the SQI. For example, if the SQI is kci.io / qos-class="extreme-low-latency", it indicates that the instance requires extremely low latency hardware topology alignment. The extended component determines that it is required and continues to execute steps 101 to 104 to complete the physical binding. If the SQI is a normal business type (such as kci.io / qos-class="general") or does not carry any SQI, the extended component determines that it is not required, directly allows the sandbox creation request, and does not perform subsequent physical alignment operations. In addition, after completing the SQI identification in the sandbox phase, the extended component records the PodID of the container instance and returns an empty response to allow sandbox creation, waiting for the subsequent actual container creation process to be triggered.

[0052] Through the preprocessing steps described above during the sandbox creation phase, this application achieves differentiated processing of target container instances: hardware topology alignment is performed only for instances with high-performance requirements (such as extremely low latency), while ordinary instances are directly allowed entry, thereby avoiding unnecessary resource binding overhead. Simultaneously, through the NRI standard's registration-subscription mechanism, extension components can intervene in the control flow during the admission suspension period of the container instance's lifecycle, achieving zero-intrusion extension to the orchestration and runtime layers.

[0053] In another embodiment, the extended component is a plugin implemented based on the node resource interface standard. Based on this, the "intercepting the instance creation request issued by the container runtime component for the target container instance" in step 101 may specifically include the following steps: establishing a communication connection between the plugin and the container runtime component; when the container runtime component triggers a lifecycle hook, intercepting the instance creation request issued by the container runtime component for the target container instance through the plugin based on the communication connection.

[0054] Node resource interface: refers to a standard extension framework provided by the container runtime. This framework allows external customized plugins to intervene in the control flow at key nodes in the container lifecycle and perform dynamic modifications to the underlying properties of the container.

[0055] A plugin is an extended component deployed on a host node, implemented based on the Node Resource Interface (NRI) standard, used to execute custom control logic at critical points in the container lifecycle. In this embodiment, the plugin is a specific implementation of the aforementioned extended component, namely a topology alignment plugin implemented based on the NRI standard.

[0056] Communication connection: refers to the connection established between the plugin and the container runtime components for data interaction. In this embodiment, the communication connection specifically refers to the plugin establishing a gRPC communication connection with the NRI microservice of the container runtime through a Unix Domain Socket (such as / var / run / nri / nri.sock).

[0057] Lifecycle hooks: These are trigger points set by the container runtime throughout the entire process of a container instance, from creation to destruction, that can be intercepted by external plugins. In this embodiment, the lifecycle hooks include at least the sandbox creation hook (RunPodSandbox) and the container creation hook (CreateContainer). When the container runtime executes these hooks, it pauses the current process, sends a request to the registered NRI plugin, and waits for a response.

[0058] In this embodiment, the extension component is a plugin implemented based on the NRI standard. The interception operation in step 101 is as follows: The plugin establishes a gRPC communication connection with the NRI microservice of the container runtime via a Unix Domain Socket. The plugin sends a registration request to the container runtime through this connection, declaring its need to subscribe to lifecycle hooks such as container creation events. When the container runtime receives a container creation instruction from the upper-layer orchestration system and prepares to execute the container creation process, it pauses the current process when the corresponding lifecycle hook is triggered and sends an instance creation request to the plugin through the established gRPC communication connection. As a legitimate extension component under the NRI standard framework, the plugin intercepts the instance creation request issued by the container runtime component for the target container instance at this lifecycle hook, thereby gaining the ability to modify the configuration of the container instance before it starts.

[0059] By adopting the NRI standard framework to implement extended components, this application can intervene in the control flow at key nodes in the container lifecycle without modifying the container runtime source code, achieving zero-intrusion extension of the underlying infrastructure. Meanwhile, as the native standard interface of the container runtime, NRI has good cross-version compatibility and maintainability, ensuring the universality and portability of this application's solution in different cloud-native environments.

[0060] Figure 2 A flowchart illustrating an embodiment of another container instance creation method provided in this application. Figure 2 The process shown is in Figure 1 Based on the illustrated process, the following steps are included: Step 201: Based on the physical hardware topology information, determine the node identifier of each non-unified memory access node included in the host node, as well as the core identifier and idle status of the physical processor core under each non-unified memory access node. Step 202: Based on the number of core requirements indicated by the computing resource requirement information, select a target non-uniform memory access node from the non-uniform memory access nodes whose number of idle physical processor cores is greater than or equal to the number of core requirements, and select a group of target physical processor cores that match the number of core requirements from the idle physical processor cores under the target non-uniform memory access node. Step 203: Generate a processor core binding mask based on the core identifier of the target physical processor core, generate a memory node binding mask based on the node identifier of the target non-uniform memory access node, and combine the processor core binding mask and the memory node binding mask into the physical binding strategy.

[0061] For ease of understanding, steps 201-203 will be explained uniformly below: Node identifier: This refers to the identification information used to uniquely identify a NUMA node. In this embodiment, each NUMA node corresponds to a unique identifier in the operating system kernel file system, such as node0 or node1. This identifier is used to specify the memory allocation domain during resource allocation.

[0062] Core Identifier: This refers to the identification information used to uniquely identify a physical processor core. In this embodiment, each physical processor core has a unique identifier in the operating system, such as core 0, core 1, core 2, etc. This identifier is used to specify the set of physical cores that virtual processor threads can run on during resource allocation.

[0063] Idle state: refers to the available state of a physical processor core that is not currently exclusively occupied by any container instance or system process. In this embodiment, when the extended component reads the physical hardware topology information through the global topology awareness module, it will simultaneously obtain the scheduling status of each physical processor core, including whether it has been bound to the cpuset of other container instances or whether there are high-load tasks, thereby filtering out the currently available idle cores.

[0064] Core Requirement Count: This refers to the number of CPU cores required by the target container instance as indicated in the computing resource requirement information. In this embodiment, the user specifies the CPU quota for the container instance through the upper-layer orchestration system. For example, if a 4-core container instance is requested, the core requirement count is 4.

[0065] Processor core binding mask: This refers to a mask configuration used at the operating system level to specify the set of physical processor cores that a virtual processor thread can run on. In this embodiment, the CPU core binding mask specifically corresponds to the cpuset.cpus configuration item under the cpuset subsystem in Cgroup, and its value is a range of physical core numbers (such as "0-3"), indicating that container instances are allowed to use cores 0, 1, 2, and 3.

[0066] Memory node binding mask: This refers to a mask configuration used at the operating system level to specify the set of NUMA nodes that a container instance can use. In this embodiment, the memory node binding mask specifically corresponds to the cpuset.mems configuration item under the cpuset subsystem in Cgroup, and its value is one or more NUMA node numbers (such as "0"), indicating that the memory allocation of the container instance is restricted to the specified NUMA nodes.

[0067] In this embodiment, the extension component generates a physical binding strategy according to the physical hardware topology information obtained in step 102 and the computing resource requirement information obtained in step 101, following these steps: First, the extension component calls the global topology awareness module to obtain the physical hardware topology information, from which it parses the node identifiers (e.g., node0, node1) of each NUMA node contained in the host node, the core identifier list of the physical processor cores under each NUMA node (e.g., cores 0, 1, 2, 3, 4, 5 under node0), and the current idle status of each physical processor core (e.g., whether it has been bound to other containers); Second, according to the core requirement number indicated in the computing resource requirement information obtained in step 101 (e.g., 4 cores required), the extension component filters out NUMA nodes from each NUMA node whose number of idle physical processor cores is greater than or equal to the core requirement number, and selects one of them as the target NUMA node (e.g., NUMA Node). (Currently, there are 4 idle cores, which meets the requirement). Then, a set of target physical processor cores matching the required number of cores is selected from the idle physical processor cores under the target NUMA node (e.g., cores 0, 1, 2, and 3). Finally, the extension component generates a processor core binding mask (e.g., cpus="0-3") based on the core identifier of the selected target physical processor cores, and generates a memory node binding mask (e.g., mems="0") based on the node identifier of the target NUMA node. The two are combined into a physical binding strategy. The core constraint of this strategy is to ensure that the virtual processor threads of the target container instance are restricted to running on the selected physical cores, and that memory allocation is restricted to the selected NUMA node.

[0068] pass Figure 2 As illustrated, this application enables the allocation of physical cores and corresponding memory resources for container instances within the same NUMA node, ensuring that virtual processor threads and the memory they access reside on the same NUMA node, thereby avoiding latency penalties associated with cross-node memory access. Furthermore, by prioritizing the allocation of NUMA nodes with sufficient idle cores, resource conflicts during resource allocation are avoided, improving the efficiency and determinism of resource allocation and enabling secure container instances to achieve deterministic low-latency performance.

[0069] Figure 3 A flowchart illustrating another embodiment of a container instance creation method provided in this application. Figure 3 The process shown is in Figure 1 Based on the illustrated process, the following steps are included: Step 301: Obtain the initial configuration information generated by the container runtime component for the target container instance. The initial configuration information includes resource limit fields and extended annotation fields. Step 302: Write the processor core binding mask in the physical binding policy into the processor core binding configuration item in the resource limit field, and write the memory node binding mask in the physical binding policy into the memory node binding configuration item in the resource limit field; Step 303: Write the control instructions used to instruct the virtual machine pad to perform processor core binding into the extended annotation field to obtain the injected runtime configuration information, and return the injected runtime configuration information to the container runtime component to replace the initial configuration information.

[0070] For ease of understanding, steps 301-303 will be explained uniformly below: Initial configuration information: refers to the standard configuration file generated by the container runtime component for the target container instance, conforming to the OCI runtime specification. In this embodiment, the initial configuration information is the config.json file, which is automatically generated by the container runtime component before the container instance starts, based on the scheduling instructions of the upper-layer orchestration system, and has not yet undergone any hardware topology alignment modifications.

[0071] Resource Limitation Field: This refers to the field area in the initial configuration information used to describe the system resource limitations of the container instance. In this embodiment, the resource limitation field is specifically the Linux.Resources field in the OCI specification. This field contains multiple sub-configuration items used to set resource control parameters such as CPU binding, memory binding, and device access.

[0072] Extended annotation fields: These refer to the field area in the initial configuration information used to pass custom extended instructions. In this embodiment, the extended annotation fields are specifically the Annotations field in the OCI specification. This field stores user- or system-attached custom metadata in key-value pairs. Container runtime components and underlying virtualization components can parse these annotations and execute the corresponding logic.

[0073] Processor core binding configuration item: This refers to the configuration item in the resource limit field used to specify the set of physical processor cores that the container instance can use. In this embodiment, the processor core binding configuration item is specifically the cpuset.cpus configuration item under the cpuset subsystem in Cgroup, and its value is a processor core binding mask (such as "0-3"), which is used to restrict all threads within the container instance to run only on the specified physical cores.

[0074] Memory node binding configuration item: This refers to the configuration item in the resource limit field used to specify the set of NUMA nodes that a container instance can use. In this embodiment, the memory node binding configuration item is specifically the cpuset.mems configuration item under the cpuset subsystem in Cgroup, and its value is a memory node binding mask (such as "0"), used to restrict the memory allocation of the container instance to the specified NUMA nodes.

[0075] Virtual machine shim: refers to the communication and lifecycle management agent process located between the container runtime and the underlying virtual machine monitor. In this embodiment, the virtual machine shim is specifically Kata Shim, whose core responsibility is to parse the container OCI specification configuration from the upper layer and translate it into underlying system startup parameters or control plane API instructions that the virtual machine monitor can recognize.

[0076] Control instructions: These are extended instructions used to instruct virtual machine pads to perform processor core binding operations. In this embodiment, the control instructions are written to extended annotation fields in the form of key-value pairs. For example, io.katacontainers.config.hypervisor.enable_vcpus_pinning="true" indicates enabling vCPU thread binding, and io.katacontainers.config.hypervisor.enable_numa="true" indicates enabling NUMA memory binding.

[0077] In this embodiment, after the extension component generates the physical binding policy in step 103, it injects the physical binding policy into the runtime configuration information of the target container instance according to the following steps: First, the extension component obtains the initial configuration information (i.e., the initial config.json) generated by the container runtime component for the target container instance. This initial configuration information includes at least the resource limit field (Linux.Resources) and the extended annotation field (Annotations). Then, the extension component writes the processor core binding mask (e.g., cpus="0-3") in the physical binding policy generated in step 103 into the processor core binding configuration item (cpuset.cpus) in the resource limit field, and writes the memory node binding mask (e.g., mems="0") in the memory node binding configuration item in the resource limit field. The `cpuset.mems` property is set; next, the extended component writes the control instructions used to instruct the virtual machine pads to execute processor core-bound commands (such as `io.katacontainers.config.hypervisor.enable_vcpus_pinning="true"` and `io.katacontainers.config.hypervisor.enable_numa="true"`) as key-value pairs into the extended annotation fields, thus obtaining the injected runtime configuration information; finally, the extended component returns the injected runtime configuration information as a response to the container runtime component to replace the initial configuration information, so that the container runtime component uses the modified configuration when starting the container instance subsequently.

[0078] pass Figure 3 As shown in the process, this application fully utilizes the standard extension capabilities of the OCI specification, allowing the physical binding strategy to be passed to the underlying execution component without modifying the source code of the container runtime or virtual machine pad. Simultaneously, by passing control instructions through annotation fields, which are natively parsed and executed by the virtual machine pad, the application achieves a non-intrusive extension to the underlying virtualization layer, exhibiting excellent cross-version compatibility and portability.

[0079] In one embodiment, the method may further include the following steps: obtaining the process identifier of the virtual machine monitor process corresponding to the target container instance; identifying a target thread belonging to the virtual processor type from the thread space of the virtual machine monitor process based on the process identifier; and calling the thread affinity setting interface provided by the operating system of the host node to forcibly bind the target thread to the physical processor core indicated by the physical binding policy.

[0080] Virtual Machine Monitor (VM) process: This refers to the low-level control process running in the host machine's user space, responsible for creating and managing micro-virtual machines. In this embodiment, the VM monitor process is specifically a VMM process, such as QEMU or the Cloud Hypervisor process. This process contains multiple threads, including a vCPU thread used to simulate a virtual CPU and execute guest instructions.

[0081] Process Identifier: A unique identifier assigned by the operating system kernel to each running process. In this embodiment, the process identifier is specifically the PID (Process Identifier), which allows the system to locate detailed information about the corresponding process in the operating system's process file system (such as the / proc file system).

[0082] Thread space: refers to the collection of all threads contained within the virtual machine monitor process. In this embodiment, the thread space can be obtained by reading the / proc / [PID] / task / directory, which lists all threads under the specified process, with each thread corresponding to a unique thread identifier.

[0083] The target thread of the virtual processor type refers to a thread in the virtual machine monitor process specifically used to simulate a virtual CPU and execute instructions from the guest operating system. In this embodiment, the target thread is specifically a vCPU thread. This thread is typically named in the host operating system with features such as "CPU" or "KVM" (e.g., "CPU 0 / KVM"). Its scheduling behavior is controlled by the host operating system kernel, and by default, it can migrate between multiple physical processor cores.

[0084] Thread affinity setting interface: This refers to the system call interface provided by the host operating system used to set the binding relationship between threads and physical processor cores. In this embodiment, the thread affinity setting interface is specifically the sched_setaffinity system call provided by the Linux kernel. This interface allows the caller to pass in a thread identifier and a physical core mask, forcibly binding the specified thread to the physical processor core indicated by the mask to run on.

[0085] In this embodiment, as an alternative implementation to the aforementioned method of injecting the physical binding strategy through the OCI specification, this application also provides the following out-of-band thread forced binding mechanism: First, the extension component obtains the process identifier (PID) of the virtual machine monitor process corresponding to the target container instance. Specifically, the extension component can obtain the PID of its underlying VMM process through the interface provided by the container runtime or by parsing the Cgroup information of the container instance. Second, based on the obtained process identifier, the extension component traverses the thread space of the process by accessing the operating system's process file system (such as / proc / [PID] / task / ) to identify the target thread (i.e., vCPU thread) belonging to the virtual processor type. The identification method can be based on specific characteristics contained in the thread name (such as "CPU" or "KVM"), or based on the thread's scheduling policy and priority characteristics. Then, the extension component calls the thread affinity setting interface provided by the host operating system (such as the sched_setaffinity system call in Linux) to forcibly bind the identified target thread to the physical processor core indicated by the physical binding strategy (e.g., binding the vCPU thread to cores 0, 1, 2, and 3). This binding operation acts directly on the host kernel scheduler after the container instance starts, without needing OCI specification injection or virtual machine pad parsing and translation. It is an out-of-band implementation that bypasses the container management plane to directly physically lock the underlying threads.

[0086] Through the aforementioned out-of-band thread binding mechanism, this application provides an alternative implementation scheme that does not rely on OCI specification injection and virtual machine pad annotation parsing. This scheme directly operates on the host kernel's thread scheduler, achieving physical affinity isolation of secure container instances even in constrained architectures where deep cooperation from the control plane is not possible. This alternative embodiment greatly enhances the platform compatibility and robustness of the proposed solution, ensuring broad applicability in various cloud-native environments.

[0087] Figure 4 A flowchart illustrating another embodiment of the container instance creation method provided in this application. Figure 4 The process shown is in Figure 1 Based on the illustrated process, the following steps are included: Step 401: When any physical processor core on the host node is detected to be offline, identify the target container instance bound to the first physical processor core where the offline event occurred from the locally stored topology mapping relationship record. Step 402: Within the non-unified memory access node to which the first physical processor core belongs, select the second physical processor core that is in an idle state, and generate an updated physical binding strategy based on the core identifier of the second physical processor core and the node identifier of the non-unified memory access node. Step 403: Call the container resource update interface provided by the container runtime component to update the processor core binding configuration item in the runtime configuration information of the target container instance to the core identifier of the second physical processor core; Step 404: Call the thread affinity setting interface provided by the operating system of the host node to forcibly migrate and bind the virtual processor thread of the target container instance to the second physical processor core.

[0088] For ease of understanding, steps 401-404 are explained uniformly below: Physical processor core offline: This refers to an event where a physical processor core on a host node is stopped from scheduling and taken offline by the operating system kernel due to hardware failure, system maintenance, or hot-swapping operations. In this embodiment, when a physical core goes offline, the operating system kernel broadcasts a cpu_offline event through a netlink socket to inform upper-layer components that the core is no longer available.

[0089] Topology mapping record: This refers to a data structure maintained in local memory by the extension component to record the binding relationship between physical processor cores and container instances. In this embodiment, the topology mapping record is specifically a precise mapping topology map of [physical core -> container instance ID -> virtual CPU thread ID]. This record is updated in real time after each successful physical binding by the extension component, and is used to quickly locate the affected container instances in the event of a failure.

[0090] Offline events: These refer to system events triggered when a physical processor core changes from an online state to an offline state. In this embodiment, the extended component establishes and maintains a long connection with the host operating system kernel's netlink socket through a global topology awareness module, capturing the cpu_offline hardware disconnection event issued by the kernel in real time.

[0091] The first physical processor core refers to the physical processor core that has gone offline, i.e., the faulty core. In this embodiment, this core was originally bound to the virtual processor threads of one or more container instances. When this core goes offline, the business threads running on it will be unable to continue to execute normally.

[0092] The second physical processor core refers to a spare physical processor core that is reselected within the NUMA node to which the failed core belongs and is currently idle. In this embodiment, the second physical processor core is used to replace the offline first physical processor core and receive the virtual processor threads originally bound to the first core.

[0093] Container resource update interface: This refers to the interface provided by the container runtime component for dynamically updating the resource configuration of a container instance during runtime. In this embodiment, the container resource update interface is specifically the UpdateContainer interface of the container runtime. Calling this interface can hot-update the Cgroup configuration of the container instance, including resource limit parameters such as cpuset.cpus.

[0094] Forced migration binding refers to the process of unbinding a running virtual processor thread from its currently bound physical processor core and rebinding it to another physical processor core. In this embodiment, forced migration binding is implemented by calling the host operating system's sched_setaffinity system call. The system kernel will preempt the original execution stack of the damaged business thread, schedule it, and lock it to a spare physical processor core.

[0095] In this embodiment, the application also provides a high-availability self-healing mechanism to cope with sudden changes in physical resources, specifically including the following steps: First, the extended component establishes and maintains a long connection with the host operating system kernel netlink socket through the global topology awareness module, and monitors the changes in the physical processor core status in real time. When any physical processor core on the host node goes offline (i.e., a cpu_offline event is received), the extended component retrieves and identifies the target container instance and its corresponding virtual processor thread identifier bound to the first physical processor core that went offline from the topology mapping relationship record stored in local memory; then, the extended component queries the NUMA node to which the first physical processor core belongs, and selects an idle core as the second physical processor core (if there are no idle cores in the same node). If the container instance is marked as "topology downgraded" in an adjacent node, an updated physical binding policy is generated based on the core identifier of the second physical processor core and the node identifier of the NUMA node. Next, the extended component calls the container resource update interface (such as the UpdateContainer interface) provided by the container runtime component to hot-update the processor core binding configuration item (cpuset.cpus) in the runtime configuration information of the target container instance to the core identifier of the second physical processor core. Finally, the extended component calls the thread affinity setting interface (sched_setaffinity system call) provided by the host operating system to unlock the virtual processor threads of the target container instance from the first physical processor core, forcibly migrate and rebind them to the second physical processor core, restoring the normal execution of business instructions. After the migration is complete, the extended component reports the underlying physical topology change event to the upper-layer Serverless management plane via the event bus. If the container instance is marked as "topology downgraded," the management plane can trigger a cross-node lossless graceful eviction process for that instance.

[0096] pass Figure 4 As illustrated, this application can detect fault events in real time and accurately locate damaged container instances when a physical processor core experiences a hardware failure. It can also quickly complete the hot migration and rebinding of virtual processor threads within the same NUMA node, avoiding service interruptions caused by core offline. Simultaneously, by prioritizing the allocation of spare cores within the same node, it ensures that memory access for virtual processor threads remains local after migration, eliminating performance degradation caused by cross-NUMA node access and achieving high availability and self-healing capabilities in fault scenarios.

[0097] To facilitate understanding of the technical solution of this application, the following will be combined with Figure 5 The present application provides an overall description of a container instance creation method provided in one embodiment.

[0098] like Figure 5 As shown, the container instance creation method provided in this application embodiment is applied to an extension component deployed on a host node. Specifically, this extension component is a topology alignment plugin implemented based on the NRI standard. During system startup, the plugin establishes a gRPC communication connection with the NRI microservice of the container runtime component via a Unix Domain Socket, and sends a RegisterPlugin registration request, declaring that it needs to subscribe to the sandbox creation event (RunPodSandbox) and the container creation event (CreateContainer), and enters a ready listening state.

[0099] When the underlying physical machine's on-site agent receives a container instance creation command from the cloud and calls the container runtime interface, it first triggers the sandbox creation process. Before preparing to launch the outer sandbox of the Kata virtual machine, the container runtime component synchronously sends a sandbox instance creation request (RunPodSandboxRequest) to the NRI plugin via the gRPC protocol. At this time, the container instance launch process is forcibly suspended. The NRI plugin receives and parses the request, extracting the service quality identifier of the target container instance from the Annotations dictionary in the PodSandboxConfig of the request body, such as kci.io / qos-class="extreme-low-latency". If the identifier indicates that hardware topology alignment is required, the NRI plugin records the Pod ID of the container instance and returns an empty response to allow sandbox creation, waiting for the subsequent container creation process to be triggered; if the identifier indicates a normal business type or does not carry any identifier, the sandbox creation request is directly allowed, and the subsequent physical alignment operation is not performed.

[0100] Once the sandbox is ready, the container runtime component generates the initial OCI specification configuration (i.e., the initial config.json) for the target container instance. When the container creation event (CreateContainer) lifecycle hook is triggered, it synchronously sends an instance creation request (CreateContainerRequest) to the NRI plugin via the gRPC protocol. This request carries the initial OCI specification configuration and computing resource requirements (e.g., the core requirement is 4 cores). At this point, the container instance startup process is suspended again.

[0101] In response to the intercepted instance creation request, the NRI plugin invokes the global topology awareness module on the host node. This module reads the / sys / devices / system / node / directory in the operating system kernel file system to obtain the physical hardware topology information of the current host node in real time, including the node identifier of each NUMA node (such as node0, node1), the memory capacity and usage status of each NUMA node, the core identifier of the physical processor cores under each NUMA node (such as core 0, 1, 2, 3), and the online / idle status of each physical processor core.

[0102] The NRI plugin performs resource allocation calculations to generate a physical binding strategy based on the acquired computing resource requirements (e.g., 4 cores required) and physical hardware topology information. Specifically, the plugin first determines the physical processor cores under each NUMA node and their idle status. It selects a target NUMA node from among the NUMA nodes with more or more idle physical processor cores than the required number of cores (e.g., NUMA Node 0 currently has 4 idle cores), and selects a set of target physical processor cores (e.g., cores 0, 1, 2, and 3) from the idle physical processor cores under that target NUMA node. Then, it generates a processor core binding mask (e.g., cpus="0-3") based on the core identifier of the target physical processor cores, and a memory node binding mask (e.g., mems="0") based on the node identifier of the target NUMA node. These two are combined into a physical binding strategy, which instructs that the virtual processor threads of the target container instance be bound one-to-one to the physical processor cores of the host node, and that the memory allocation domain of the target container instance and the bound physical processor core belong to the same NUMA node.

[0103] The NRI plugin injects the physical binding strategy into the runtime configuration information of the target container instance: First, it obtains the initial OCI specification configuration generated by the container runtime component for the target container instance, writes the processor core binding mask into the processor core binding configuration item (cpuset.cpus) in the resource limit field (Linux.Resources), writes the memory node binding mask into the memory node binding configuration item (cpuset.mems), and writes the control instructions used to instruct the virtual machine shim (Kata Shim) to execute processor core binding (such as io.katacontainers.config.hypervisor.enable_vcpus_pinning="true" and io.katacontainers.config.hypervisor.enable_numa="true") into the extended annotation field (Annotations) to obtain the injected runtime configuration information, and returns this configuration information as a response to the container runtime component to replace the initial configuration.

[0104] Upon receiving the response, the container runtime component releases the suspended state and starts the target container instance based on the injected runtime configuration information. The virtual machine pad parses the binding instructions in the configuration, translates them into startup parameters and system calls for the VMM (such as QEMU or CloudHypervisor), and finally, at the moment the underlying micro-virtual machine starts, forcibly locks the virtual processor thread to the physical processor core specified by the physical binding policy and forcibly allocates memory within the specified NUMA node.

[0105] Through the above process, this application establishes a fine-grained resource binding relationship that penetrates the virtual machine boundary during the container instance startup phase, fundamentally avoiding the drift of virtual processor threads between physical processor cores. At the same time, it ensures that the memory allocation domain and the virtual processor threads are located in the same NUMA node, eliminating the latency overhead caused by cross-node memory access, effectively suppressing performance jitter, and meeting the requirements of high-performance business scenarios for deterministic computing resources and low latency.

[0106] Figure 6 This is a block diagram illustrating an embodiment of a container instance creation apparatus provided in this application. Figure 6 As shown, the device includes: The interception module 61 is used to intercept the instance creation request issued by the container runtime component for the target container instance, and to obtain the computing resource requirement information of the target container instance from the instance creation request. The acquisition module 62 is used to acquire the physical hardware topology information of the host node where the target container instance is located in response to the interception of the instance creation request; The generation module 63 is used to generate a physical binding strategy based on the computing resource requirement information and the physical hardware topology information. The physical binding strategy is used to indicate that the virtual processor thread of the target container instance is bound one-to-one with the physical processor core of the host node, and that the memory allocation domain of the target container instance and the bound physical processor core belong to the same non-uniform memory access node. The injection module 64 is used to inject the physical binding strategy into the runtime configuration information of the target container instance, and start the target container instance according to the injected runtime configuration information, so that the virtual processor thread of the target container instance is forcibly locked to the physical processor core, and the memory of the target container instance is forcibly allocated within the non-uniform memory access node.

[0107] In one possible implementation, the apparatus further includes a setup module for: Establish a communication channel between the host node and the container runtime component; A registration request is sent to the container runtime component through the communication channel. The registration request is used to declare the types of lifecycle events that need to be intercepted. When the container runtime component triggers the sandbox creation event according to the registration request, it receives the sandbox instance creation request sent by the container runtime component through the communication channel, and extracts the service quality identifier of the target container instance from the sandbox instance creation request; When it is determined, based on the quality of service identifier, that the target container instance needs to perform hardware topology alignment, the step of intercepting the instance creation request issued by the container runtime component for the target container instance is executed.

[0108] In one possible implementation, the generation module is specifically used for: Based on the physical hardware topology information, determine the node identifier of each non-unified memory access node included in the host node, as well as the core identifier and idle status of the physical processor core under each non-unified memory access node. Based on the number of core requirements indicated by the computing resource requirement information, a target non-uniform memory access node is selected from non-uniform memory access nodes whose number of idle physical processor cores is greater than or equal to the number of core requirements, and a set of target physical processor cores matching the number of core requirements is selected from the idle physical processor cores under the target non-uniform memory access node. A processor core binding mask is generated based on the core identifier of the target physical processor core, a memory node binding mask is generated based on the node identifier of the target non-uniform memory access node, and the processor core binding mask and the memory node binding mask are combined into the physical binding strategy.

[0109] In one possible implementation, the injection module is specifically used for: Obtain the initial configuration information generated by the container runtime component for the target container instance, the initial configuration information including resource limit fields and extended annotation fields; Write the processor core binding mask in the physical binding policy into the processor core binding configuration item in the resource limit field, and write the memory node binding mask in the physical binding policy into the memory node binding configuration item in the resource limit field; The control instructions used to instruct the virtual machine pad to perform processor core binding are written into the extended annotation field to obtain the injected runtime configuration information, and the injected runtime configuration information is returned to the container runtime component to replace the initial configuration information.

[0110] In one possible implementation, the apparatus further includes a first invocation module for: Obtain the process identifier of the virtual machine monitor process corresponding to the target container instance; Based on the process identifier, a target thread belonging to the virtual processor type is identified from the thread space of the virtual machine monitor process; The thread affinity setting interface provided by the operating system of the host node is invoked to forcibly bind the target thread to the physical processor core indicated by the physical binding policy.

[0111] In one possible implementation, the device further includes a second calling module for: When any physical processor core on the host node is detected to be offline, the target container instance bound to the first physical processor core where the offline event occurred is identified from the locally stored topology mapping record. Within the non-unified memory access node to which the first physical processor core belongs, a second physical processor core that is in an idle state is selected, and an updated physical binding strategy is generated based on the core identifier of the second physical processor core and the node identifier of the non-unified memory access node. Call the container resource update interface provided by the container runtime component to update the processor core binding configuration item in the runtime configuration information of the target container instance to the core identifier of the second physical processor core; The thread affinity setting interface provided by the operating system of the host node is invoked to forcibly migrate and bind the virtual processor thread of the target container instance to the second physical processor core.

[0112] In one possible implementation, the extension component is a plugin based on the node resource interface standard; The interception module is specifically used for: Establish a communication connection between the plugin and the container runtime component; When the container runtime component triggers a lifecycle hook, the plugin intercepts the instance creation request issued by the container runtime component for the target container instance based on the communication connection.

[0113] like Figure 7 As shown in the figure, this application provides a device including a processor 111, a communication interface 112, a memory 113, and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114. Memory 113 is used to store computer programs; In one embodiment of this application, when the processor 111 executes a program stored in the memory 113, it implements the container instance creation method provided in any of the foregoing method embodiments, including: Intercept the instance creation request issued by the container runtime component for the target container instance, and obtain the computing resource requirement information of the target container instance from the instance creation request; In response to intercepting the instance creation request, obtain the physical hardware topology information of the host node where the target container instance is located; Based on the computing resource requirement information and the physical hardware topology information, a physical binding strategy is generated, wherein the physical binding strategy is used to indicate that: the virtual processor thread of the target container instance is bound one-to-one with the physical processor core of the host node, and the memory allocation domain of the target container instance and the bound physical processor core belong to the same non-uniform memory access node. The physical binding strategy is injected into the runtime configuration information of the target container instance, and the target container instance is started according to the injected runtime configuration information, so that the virtual processor thread of the target container instance is forcibly locked to the physical processor core, and the memory of the target container instance is forcibly allocated within the non-uniform memory access node.

[0114] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the container instance creation method provided in any of the foregoing method embodiments.

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

[0116] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0117] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0118] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for creating a container instance, characterized in that, The method, applied to an extended component deployed on a host node, includes: Intercept the instance creation request issued by the container runtime component for the target container instance, and obtain the computing resource requirement information of the target container instance from the instance creation request; In response to intercepting the instance creation request, obtain the physical hardware topology information of the host node where the target container instance is located; Based on the computing resource requirement information and the physical hardware topology information, a physical binding strategy is generated, wherein the physical binding strategy is used to indicate that: the virtual processor thread of the target container instance is bound one-to-one with the physical processor core of the host node, and the memory allocation domain of the target container instance and the bound physical processor core belong to the same non-uniform memory access node. The physical binding strategy is injected into the runtime configuration information of the target container instance, and the target container instance is started according to the injected runtime configuration information, so that the virtual processor thread of the target container instance is forcibly locked to the physical processor core, and the memory of the target container instance is forcibly allocated within the non-uniform memory access node.

2. The method according to claim 1, characterized in that, Before the interception of the instance creation request issued by the container runtime component for the target container instance, the following is also included: Establish a communication channel between the host node and the container runtime component; A registration request is sent to the container runtime component through the communication channel. The registration request is used to declare the types of lifecycle events that need to be intercepted. When the container runtime component triggers the sandbox creation event according to the registration request, it receives the sandbox instance creation request sent by the container runtime component through the communication channel, and extracts the service quality identifier of the target container instance from the sandbox instance creation request; When it is determined, based on the quality of service identifier, that the target container instance needs to perform hardware topology alignment, the step of intercepting the instance creation request issued by the container runtime component for the target container instance is executed.

3. The method according to claim 1, characterized in that, The step of generating a physical binding strategy based on the computing resource requirement information and the physical hardware topology information includes: Based on the physical hardware topology information, determine the node identifier of each non-unified memory access node included in the host node, as well as the core identifier and idle status of the physical processor core under each non-unified memory access node. Based on the number of core requirements indicated by the computing resource requirement information, a target non-uniform memory access node is selected from non-uniform memory access nodes whose number of idle physical processor cores is greater than or equal to the number of core requirements, and a set of target physical processor cores matching the number of core requirements is selected from the idle physical processor cores under the target non-uniform memory access node. A processor core binding mask is generated based on the core identifier of the target physical processor core, a memory node binding mask is generated based on the node identifier of the target non-uniform memory access node, and the processor core binding mask and the memory node binding mask are combined into the physical binding strategy.

4. The method according to claim 1, characterized in that, The step of injecting the physical binding policy into the runtime configuration information of the target container instance includes: Obtain the initial configuration information generated by the container runtime component for the target container instance, the initial configuration information including resource limit fields and extended annotation fields; Write the processor core binding mask in the physical binding policy into the processor core binding configuration item in the resource limit field, and write the memory node binding mask in the physical binding policy into the memory node binding configuration item in the resource limit field; The control instructions used to instruct the virtual machine pad to perform processor core binding are written into the extended annotation field to obtain the injected runtime configuration information, and the injected runtime configuration information is returned to the container runtime component to replace the initial configuration information.

5. The method according to claim 1, characterized in that, The method further includes: Obtain the process identifier of the virtual machine monitor process corresponding to the target container instance; Based on the process identifier, a target thread belonging to the virtual processor type is identified from the thread space of the virtual machine monitor process; The thread affinity setting interface provided by the operating system of the host node is invoked to forcibly bind the target thread to the physical processor core indicated by the physical binding policy.

6. The method according to claim 1, characterized in that, After starting the target container instance based on the injected runtime configuration information, the process further includes: When any physical processor core on the host node is detected to be offline, the target container instance bound to the first physical processor core where the offline event occurred is identified from the locally stored topology mapping record. Within the non-unified memory access node to which the first physical processor core belongs, a second physical processor core that is in an idle state is selected, and an updated physical binding strategy is generated based on the core identifier of the second physical processor core and the node identifier of the non-unified memory access node. Call the container resource update interface provided by the container runtime component to update the processor core binding configuration item in the runtime configuration information of the target container instance to the core identifier of the second physical processor core; The thread affinity setting interface provided by the operating system of the host node is invoked to forcibly migrate and bind the virtual processor thread of the target container instance to the second physical processor core.

7. The method according to claim 1, characterized in that, The extended component is a plugin implemented based on the node resource interface standard; The interception of instance creation requests issued by the container runtime component against the target container instance includes: Establish a communication connection between the plugin and the container runtime component; When the container runtime component triggers a lifecycle hook, the plugin intercepts the instance creation request issued by the container runtime component for the target container instance based on the communication connection.

8. A container instance creation apparatus, characterized in that, The device includes: The interception module is used to intercept instance creation requests issued by the container runtime component for the target container instance, and to obtain the computing resource requirement information of the target container instance from the instance creation request. The acquisition module is used to acquire the physical hardware topology information of the host node where the target container instance is located in response to the interception of the instance creation request; The generation module is used to generate a physical binding strategy based on the computing resource requirement information and the physical hardware topology information. The physical binding strategy is used to indicate that the virtual processor thread of the target container instance is bound to the physical processor core of the host node in a one-to-one manner, and that the memory allocation domain of the target container instance and the bound physical processor core belong to the same non-uniform memory access node. The injection module is used to inject the physical binding strategy into the runtime configuration information of the target container instance, and start the target container instance according to the injected runtime configuration information, so that the virtual processor thread of the target container instance is forcibly locked to the physical processor core, and the memory of the target container instance is forcibly allocated within the non-uniform memory access node.

9. An electronic device, characterized in that, include: A processor and a memory, the processor being configured to execute a container instance creation program stored in the memory to implement the container instance creation method according to any one of claims 1-7.

10. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the container instance creation method according to any one of claims 1-7.

Images