Secure container migration method and device, storage medium and program product

Abstract

The embodiment of the invention provides a secure container migration method and device, a storage medium and a program product. A first security container on a source node comprises a target resource object and a non-target resource object, and under the condition that the target resource object is realized as a direct connection device of the security container, aiming at different characteristics of the target resource object and the non-target resource object, through mutual cooperation of different hierarchical components, the target resource object and the non-target resource object can be directly connected. That is, the state data of the target resource object and the non-target resource object in the first security container are obtained through the drive program of the target resource object and the container runtime component, so that the state data of the target resource object and the non-target resource object can be migrated to the second security container on the target node more accurately. Through mutual cooperation of different hierarchical components, rapid migration of the workload in the security container can be well completed, and the problem of state migration of the security container with the security container or a target resource object which cannot be directly managed by a cloud manufacturer to which the security container belongs is solved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a secure container migration method, device, storage medium, and program product. Background Technology

[0002] In cloud computing environments, multi-tenant architectures are typically used on a single server node. To achieve secure isolation between different tenants, containerization technology can be used to package applications and their dependencies into independent containers, ensuring application security and consistency. Secure containers, as a branch of container technology, aim to combine the security of virtualization with the convenience of containers to achieve more thorough isolation between containers, providing a higher level of isolation and protection for applications within containers, and are therefore widely used.

[0003] As a crucial application scenario for cloud computing, AI (Artificial Intelligence) intelligent computing is seeing an increasing number of AI applications and AI frameworks used for developing and deploying these applications deployed within secure containers. This has led to a growing demand for computing resources within these containers. GPUs (Graphics Processing Units), as a high-performance computing resource provided by cloud vendors, have demonstrated powerful capabilities in the fields of AI and deep learning. Therefore, some cloud vendors have proposed using GPUs within secure containers to provide computing power for applications within these containers.

[0004] Combining GPUs with secure containers can address the computing power requirements of secure containers while maintaining secure isolation. However, this approach also presents new technical challenges. For instance, in situations such as application upgrades, resource optimization, or application failures, it is necessary to migrate secure containers. How to migrate secure containers with GPU resources is a pressing technical problem that needs to be solved. Summary of the Invention

[0005] This application provides a secure container migration method, apparatus, storage medium, and program product to solve the migration problem of secure containers with GPU resources.

[0006] This application provides a secure container migration method for migrating workloads in a first secure container on a source node. The first secure container includes a target resource object and non-target resource objects. The target resource object is a pass-through device of the first secure container. The method includes: during the operation of the first secure container, pausing the operation of the target resource object of the first secure container through the driver of the target resource object, and obtaining the status data of the target resource object of the first secure container; migrating the status data of the target resource object of the first secure container to the target resource object of a second secure container, the second secure container being a secure container on the target node; pausing the operation of the first secure container through the container runtime component corresponding to the first secure container, and obtaining the status data of the non-target resource object of the first secure container; migrating the status data of the non-target resource object of the first secure container to the non-target resource object of the second secure container, thereby migrating the workload in the first secure container to the second secure container.

[0007] This application also provides a secure container migration method for migrating the workload of a first secure container on a source node, wherein a second secure container is created on a target node, the second secure container including a target resource object managed by a driver and a non-target resource object not managed by a driver; the method includes: receiving state data of the target resource object of the first secure container and storing the state data of the target resource object of the first secure container in the target resource object of the second secure container; receiving state data of the non-target resource object of the first secure container and storing the state data of the non-target resource object of the first secure container in the non-target resource object of the second secure container.

[0008] This application embodiment also provides a computer device that can be implemented as a source node. The source node includes a host machine, on which a first secure container and a container runtime component are deployed. The first secure container includes a target resource object and a non-target resource object. The target resource object is a passthrough device of the first secure container. The container runtime component is used to execute the steps in the secure container migration method.

[0009] This application also provides a computer device, including: a memory and a processor; the memory is used to store a computer program, and the processor is coupled to the memory and used to execute the computer program in the memory to implement the steps in the secure container migration method.

[0010] This application also provides a computer-readable storage medium that, when executed by a processor, enables the processor to implement the steps in the secure container migration method.

[0011] This application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, performs the steps in the secure container migration method.

[0012] This application embodiment also provides a cloud computing system, including: a source node for executing the first set of secure container migration methods described above, and a target node for executing the second set of secure container migration methods described above; the source node and the target node cooperate with each other to migrate the workload in the first secure container on the source node to the second secure container on the target node.

[0013] In this embodiment, the first secure container on the source node includes a target resource object and non-target resource objects. When the target resource object is implemented as a pass-through device for the first secure container, different layers of components can work together to address the different characteristics of the target and non-target resource objects. Specifically, the state data of the target and non-target resource objects in the first secure container can be obtained through the driver program of the target resource object and the container runtime component. This allows for a relatively accurate migration of the state data of the target and non-target resource objects to the second secure container on the target node. This method, through the cooperation of different layers of components, effectively enables rapid migration of workloads within the secure container, solving the problem of state migration for secure containers containing target resource objects that cannot be directly managed by the secure container or its cloud vendor. Attached Figure Description

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

[0015] Figure 1a A system architecture diagram of a computer device carrying a security container provided for an exemplary embodiment of this application;

[0016] Figure 1b Another system architecture diagram of a computer device carrying a security container provided for an exemplary embodiment of this application;

[0017] Figure 2a A schematic diagram of the interaction process for state transition between a source node and a target node provided in an exemplary embodiment of this application;

[0018] Figure 2bThis is a schematic diagram of another interaction process for state transition between a source node and a target node, provided as an exemplary embodiment of this application.

[0019] Figure 3 A flowchart illustrating a secure container migration method provided as an exemplary embodiment of this application;

[0020] Figure 4 A flowchart illustrating another secure container migration method provided as an exemplary embodiment of this application;

[0021] Figures 5-6 A schematic diagram of a secure container migration apparatus provided in an exemplary embodiment of this application;

[0022] Figure 7 A schematic diagram of a computer device provided for an exemplary embodiment of this application. Detailed Implementation

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

[0024] It should be noted that, in the cases involving user information in the embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.

[0025] With the deployment of AI applications and frameworks in secure containers, the demands on computing resources for secure containers are increasing. AI frameworks refer to frameworks used for developing and deploying AI applications, such as TensorFlow (an open-source machine learning platform), PyTorch (an open-source machine learning library), or Caffe (a deep learning framework that combines expressiveness, speed, and modularity). AI applications refer to applications developed and deployed based on AI frameworks, such as AI-based image processing programs, video processing programs, or game programs.

[0026] Secure containers are secure, isolated container runtime environments provided through virtualization technology. Unlike traditional container runtime environments, secure containers come with a complete operating system (i.e., the guest operating system). Traditional container runtime environments do not have a guest operating system and rely on the host machine's operating system. Based on this difference, secure containers offer higher security and isolation compared to traditional containers.

[0027] For example, Figure 1a This is a system architecture diagram of a computer device 1 housing a secure container. This computer device 1 can be implemented as any electronic device, such as a mobile phone, tablet, calculator, or any type of server; this embodiment does not impose any limitations. Figure 1a As shown, the computer device 1 may include a host machine, which includes the host machine's user space 11 (also known as the host machine's user mode), the host machine's operating system 12 (also known as the host machine's kernel mode), and a hardware layer 13. The hardware layer 13 includes various hardware resources of the host machine, such as, but not limited to, a GPU 131, a CPU (Central Processing Unit) 132, and a network interface card (NIC). Figure 1a In this example, a network interface card (NIC) 133 implementing RDMA (Remote Direct Memory Access) is used, but it is not limited to this; a regular NIC can also be used. The host operating system 12 refers to the operating system running on the host machine, which is the foundation of secure containers and virtualization technologies. It may include drivers for various hardware resources on the host machine, as well as a virtualization manager. The virtualization manager may be, but is not limited to, KVM (Kernel-based Virtual Machine). Figure 1a The diagram uses KVM 121 as an example of a virtualization manager. KVM enables the host operating system 12 to become a virtual machine monitor, allowing users to run multiple virtualization instances on the host operating system. The host's user space 11 is used to host various virtualization instances running on the host, such as secure containers 111 and container runtime components 112.

[0028] The secure container 111 can implement its core functions and features through the container runtime component 112. The container runtime component 112 is a series of software components responsible for managing the secure container in a containerized environment. These components work together to provide functions such as creating, starting, stopping, and monitoring the secure container 111, and ensure that the secure container can run securely in an isolated environment. In this embodiment, the implementation method of the container runtime component 112 is not limited; for example, it can use, but is limited to, Docker, RunC, and RunD. Docker is one of the more popular container runtimes, providing complete container management functions. RunC is a lightweight container runtime and is the foundation of Docker and other container tools. RunD is a lightweight secure container solution that provides a secure environment to run containerized applications, designed to provide enhanced security and isolation to protect sensitive data and applications from potential threats. RunD contains several key components, one of which is the RunD VMM (Virtual Machine Manager), a lightweight hypervisor used to manage and run virtual machine instances.

[0029] The secure container 111 may include an application 1111 and a guest operating system 1112. The guest operating system 1112 within the secure container 111 represents an independent and isolated runtime environment, which may be a virtual machine, but is not limited thereto. The application 1111 may be implemented as the AI ​​framework or AI application mentioned earlier, or as any other type of application framework or application; this embodiment does not impose any limitations. Relative to the guest operating system 1112, the application 1111 may reside in the user space of the secure container 111. It should be noted that the user space 11 of the secure container 111 may include other components besides the application 1111.

[0030] The guest operating system 1112 refers to the operating system running inside the secure container 111. It provides fine-grained access control, encrypted data storage, and a trusted execution environment to ensure the protection of applications and data within the container. Access control restricts process access to resources based on security policies, encrypted data storage protects data within the container using encryption technology, and the trusted execution environment provides a higher level of security. The guest operating system 1112 includes drivers for various hardware resources contained within the secure container, such as drivers that pass through to various hardware resources within the secure container using passthrough technology.

[0031] In this embodiment, introducing GPU resources into the secure container scenario can solve the problem of secure containers' demand for computing resources. It should be noted that, in addition to GPU resources, similar resources such as NPU (Neural Processing Unit) and DPU (Data Processing Unit) can also be used as computing resources for secure containers. In this embodiment, GPU, NPU, DPU, and other resources are collectively referred to as target resource objects. First, target resource objects refer to hardware computing resources; second, target resource objects refer to computing resources that do not inherently support virtualization or for which mature and standardized virtualization solutions do not yet exist. For example, TPU (Tensor Processing Unit, a simple matrix multiplication coprocessor directly connected to the host motherboard) does not have built-in scheduling capabilities and therefore does not support virtualization. As another example, GPUs are mainly responsible for handling complex computing tasks and have large built-in graphics memory. Although some virtualization solutions have emerged, most face challenges in resource allocation in multi-tenant environments and security issues between different tenant information, and are not yet mature or standardized. In contrast, resources such as CPU, network card, and memory have relatively mature and standardized virtualization solutions, and these resources are referred to as non-target resource objects.

[0032] In this embodiment, the secure container (or the cloud vendor to which the secure container belongs) has certain management and control requirements for resource objects. These management and control requirements refer to management and control related to the secure container, such as creating, destroying, and migrating the secure container, all of which involve the management and control of related resource objects. The implementation method of managing resource objects at the secure container level will differ depending on whether the resource object supports virtualization technology or whether mature virtualization technology exists. For resource objects that support virtualization technology and have mature virtualization technology, such as CPU, network card, and memory, the cloud vendor to which the secure container belongs can implement the management and control logic for these resource objects in the container runtime component 112 within the secure container, without relying on the drivers for these resource objects. That is, the management and control logic for resource objects at the secure container level does not need to be implemented in the driver for the resource objects. In this way, the cloud vendor to which the secure container belongs can implement the management and control logic for these resource objects independently, without relying on the vendor of the resource objects. For resource objects that do not support virtualization technology or lack mature virtualization technology, such as GPUs and TPUs, managing resource objects from the secure container level requires relying on the resource object's driver. This means that the relevant API interfaces exposed by the driver need to be called. As a result, the cloud vendor that owns the secure container cannot implement the management logic for these resource objects on its own and needs to rely on the device vendor's implementation of the driver.

[0033] Based on the above, the various resource objects involved in a secure container can be divided into two categories: target resource objects and non-target resource objects. Non-target resource objects refer to resource objects whose management logic can be implemented within the container runtime component 112 of the secure container based on virtualization technology. Management of non-target resource objects at the secure container level does not depend on their drivers. Target resource objects refer to resource objects whose management logic cannot be implemented within the container runtime component 112 of the secure container based on virtualization technology. Management of target resource objects at the secure container level depends on their drivers.

[0034] Because the target resource object itself does not support virtualization or the virtualization scheme is immature, the target resource object cannot be directly applied to the secure container 111 based on virtualization methods like resources such as CPU and memory. This raises the primary issue of how to apply the target resource object to the secure container 111. Therefore, this application provides two implementation methods:

[0035] Implementation Method 1: Extend the functionality of the driver for the target resource object (e.g., GPU) by adding a virtualization module (referred to as the virtualization module). This module divides the target resource object (e.g., GPU) into multiple virtual computing resources (virtual GPUs), which are then provided to the secure container 111. The driver for the target resource object resides in the host operating system 12 and needs to provide an API (Application Programming Interface). This allows the secure container 111 to obtain relevant status information about the target resource object by calling the API, facilitating its migration. However, since the driver resides in the host operating system, this involves interaction with the host kernel, which can increase computing power consumption and lead to wasted computing power. Furthermore, because the driver is a proprietary solution of the target resource object vendor, cloud providers have difficulty controlling the technical details and extending the driver's functionality.

[0036] Implementation Method 2: A passthrough technique is used to directly connect the target resource object to the secure container 111, forming an overall architecture of secure container 111 + passthrough device. In this passthrough approach, the target resource object can be referred to as the passthrough device of the secure container 111. The passthrough technique allows the secure container 111 to directly access the target resource object, instead of indirectly accessing it through the host operating system 12. Because the passthrough technique allows the secure container 111 to directly access the target resource object, it reduces the overhead of the host operating system 12, improving I / O (Input / Output) performance; simultaneously, it reduces the number of times data is copied between the host operating system 12 and the secure container 111, reducing latency and increasing throughput.

[0037] This application does not limit the passthrough technology used, such as SR-IOV (Single Root I / O Virtualization, a virtualization technology) or PCI Passthrough (Peripheral Component Interconnect Passthrough). SR-IOV can be used to enable physical devices such as network adapters and GPUs to directly provide virtual functions (VFs) to multiple virtual machines. Each virtual function can be configured independently and can directly access the host machine's hardware resources. PCI Passthrough can be used to pass physical devices such as network adapters and GPUs to secure containers, allowing the secure containers to directly access these physical devices, which can be called passthrough devices.

[0038] In some preferred embodiments, device passthrough can also be achieved based on VFIO (Virtual Function I / O) technology. VFIO is a module that enables passthrough for PCI devices on the host machine. PCI devices refer to external devices interconnected with the host machine's CPU via the PCI (Peripheral Component Interconnect) bus or the PCIe (Peripheral Component Interconnect Express) bus. Figure 1b The example computer device is illustrated using VFIO to implement pass-through from the target resource object to the secure container. Figure 1b The computer equipment shown is Figure 1aThe difference between the computer devices shown is that, in addition to KVM 121, the host operating system 12 also includes VFIO 122 and drivers for various hardware resources on the host machine; VFIO 122 can directly pass target resource objects (such as GPUs) to the secure container for use, which is beneficial to improving the efficiency of the secure container's access to the GPU; in addition, in Figure 1b The computer device shown is illustrated using an AI framework as an example, along with AI application services developed and deployed based on that framework. The user space 1110 on the client machine also includes a runtime library for the target resource object. Figure 1b The diagram below uses the GPU runtime library as an example.

[0039] The AI ​​framework can be PyTorch or Tensorflow, etc. PyTorch is an open-source machine learning library for building and training deep learning models, while Tensorflow is an open-source machine learning framework for building and training various types of machine learning models. AI application services can include inference services for large language models, image recognition services, natural language processing services, search advertising recommendation services, and function computation services, etc., but this embodiment does not impose any limitations.

[0040] When the target resource object is implemented as a passthrough device of the secure container 111, the driver for the target resource object resides in the guest operating system 1112. For example, if the target resource object is a GPU, the guest operating system 1112 includes a GPU driver. Correspondingly, for non-target resource objects that are not implemented as passthrough devices of the secure container 111, their drivers reside in the host operating system 12. Of course, the host operating system 12 also includes virtualization-related functions such as KVM and VFIO.

[0041] Through the architecture of secure container + passthrough device described above, when the secure container interacts with target resource objects (such as GPU), it can effectively reduce the overhead of the host operating system and improve I / O (Input / Output) performance; at the same time, it can reduce the number of times data is copied between the host operating system and the secure container, reduce latency and increase throughput.

[0042] The following will describe in detail the method for state transition of secure containers under the above-described pass-through architecture, taking the interaction process between any two nodes as an example. For ease of description, "source node" and "target node" will be used to describe any two nodes. This application does not limit the implementation form of the source node and target node. Taking the host machine dimension as an example, the source node can be implemented as the host machine that needs to undergo state transition, and the target node can be implemented as another host machine; taking the GPU dimension as an example, the source node can be implemented as the GPU on the host machine that needs to undergo state transition, and the target node can be implemented as another GPU. The two GPUs can be located on the same host machine or on different host machines, and there is no limitation on this.

[0043] Figure 2a This diagram illustrates the interaction flow for state migration between a source node and a target node, used to migrate workloads within a first secure container on the source node. The first secure container refers to the secure container on the source node from which state migration is required. The workload within the first secure container primarily refers to the state data of the resource objects involved in the first secure container. Migrating the workload within the first secure container mainly involves migrating the state of the resource objects included in the first secure container. These resource objects may include target resource objects managed by a driver and non-target resource objects not managed by a driver. Migrating the workload within the first secure container includes migrating the state data of the target resource objects within the first secure container and migrating the state data of the non-target resource objects within the first secure container.

[0044] For example, taking a GPU as the target resource object, the workload in the first secure container may include GPU state data (e.g., the memory list and its corresponding memory contents, other states in the GPU), CPU state data (e.g., CPU register states), storage and network state data (e.g., user temporary storage data, network addresses, disk status, etc.), memory state data (e.g., kernel data and user data of the secure container), and metadata of the secure container (e.g., management data of the secure container, information of the container engine layer, etc.). Among these, the GPU state data belongs to the target resource object's state data, while the CPU state data, storage and network state data, memory state data, and metadata of the secure container belong to the non-target resource object's state data. Based on this, the GPU state data, CPU state data storage, network state data, memory state data, and metadata of the secure container can be migrated from the first secure container to the second secure container, thereby completing the migration process of the workload in the first secure container.

[0045] like Figure 2aAs shown, state transition between the source node and the target node can be achieved based on the following steps:

[0046] Step S1: During the operation of the first secure container, the operation of the target resource object of the first secure container is paused through the driver of the target resource object.

[0047] Step S2: Obtain the state data of the target resource object of the first security container through the driver of the target resource object.

[0048] Step S3: Instruct the creation of a second security container on the target node; the second security container includes target resource objects that depend on driver management and non-target resource objects that do not depend on driver management.

[0049] Step S4: Migrate the state data of the target resource object in the first security container to the target resource object in the second security container.

[0050] Step S5: Receive the status data of the target resource object of the first security container, and save the status data of the target resource object of the first security container in the target resource object of the second security container.

[0051] Step S6: Pause the operation of the first secure container through the container runtime component corresponding to the first secure container.

[0052] Step S7: Obtain the state data of the non-target resource object of the first security container through the container runtime component corresponding to the first security container.

[0053] Step S8: Migrate the state data of the non-target resource object in the first security container to the non-target resource object in the second security container.

[0054] Step S9: Receive the status data of the non-target resource object of the first security container, and save the status data of the non-target resource object of the first security container in the non-target resource object of the second security container, so as to migrate the workload in the first security container to the second security container.

[0055] In this embodiment, the target resource object refers to a resource object that the cloud vendor or security container cannot directly manage, but requires management / control through a driver. This is generally a hardware resource object directly connected to the security container, such as a GPU, DPU, or NPU. Conversely, the target resource object refers to a resource object that the cloud vendor or security container can directly manage, without requiring program control / control. This can be a hardware resource object such as a CPU, memory, or network card; it can also be a virtual resource object created through virtualization technology, such as a virtual CPU, virtual memory, or virtual network card; or it can be a software resource object, such as engine information and node information related to the Pod metadata of a security container. A Pod is the smallest scheduling unit in Kubernetes, which can be understood as a specific security container cluster, containing one or more security containers. Kubernetes, often abbreviated as k8s, is an open-source container orchestration platform used for automatically deploying, scaling, and operating containerized applications. Engine information typically refers to configuration information related to the Pod's runtime environment, while node information refers to metadata related to the node to which the Pod is scheduled.

[0056] In this embodiment, the state data of the target resource object is acquired and saved through the driver program of the target resource object in the guest operating system of the first secure container. Acquiring and saving the state data of the target resource object through the driver program depends on the normal operation of the first secure container and the stability of the target resource object's state data. Therefore, during the operation of the first secure container, the execution of the target resource object can be paused through the driver program, and the state data of the target resource object can be acquired while it is paused, thus maintaining the consistency of the target resource object's state data. The state data of the target resource object describes its current state. If the target resource object has video memory, its state data may include a video memory list, video memory content, and other state data. Other state data refers to state data other than the video memory list and its corresponding video memory content, such as at least one of the target resource object's internal register information, working status information, and configuration information. The video memory list refers to the list of video memory regions allocated to different applications on the target resource object. Register information describes the current state of the registers, such as their values, IDs (IdentityDocument), or types. Configuration information describes various parameters and settings of the target resource object, such as enabling / disabling graphics card functions, performance settings, or display modes. Working status information describes the working state of the target resource object, including at least one of the following: the target resource object's ID, power status, and task allocation.

[0057] In this embodiment, a second secure container can be created on the target node to migrate the workload of the first secure container, but the timing of creating the second secure container is not limited. For example, after obtaining the state data of the target resource objects in the first secure container, an instruction can be given to create the second secure container on the target node. The embodiment shown in Figure 2 is illustrated as an example, but it is not limited to this. Alternatively, the second secure container can be created on the target node before migrating the workload in the first secure container. The creation time of the second secure container is not limited, as long as it is created before the workload migration to the second secure container. The second secure container also needs to include target resource objects managed by the driver and non-target resource objects not managed by the driver. It should be noted that the number and type of target resource objects contained in the second secure container need to match the number and type of target resource objects contained in the first secure container. Matching means that the types of target resource objects are the same, and the number of target resource objects contained in the second secure container must be greater than or equal to the number of target resource objects to be migrated from the first secure container, so that the state data of the target resource objects in the first secure container can be successfully migrated to the target resource objects in the second secure container. The second secure container refers to a secure container created on the target node. The terms "first" and "second" are used to distinguish between the secure containers on the source and target nodes, and do not restrict the configuration or type of the secure container. This application does not limit the specific implementation of creating the second secure container. In some exemplary embodiments, KataContainers can be used to create the second secure container. KataContainers is a lightweight virtualization technology that combines the convenience of containers with the security isolation features of virtual machines, and can be used to create a second secure container. Furthermore, the second secure container can be created by the container runtime component on the source node instructing the target node to create it, or it can be created by the control node instructing the target node to create it; this is not limited. Based on the creation of the second secure container on the target node, the state data of the target resource object in the first secure container can be migrated to the target resource object in the second secure container.

[0058] Using the methods described above, the state data of the target resource object can be further migrated during the operation of the first secure container by creating a secure container on the target node. The migration process for the state data of non-target resource objects will be explained below.

[0059] Considering that secure containers can manage non-target resource objects without relying on their drivers, but rather through container runtime components, unlike the previous method of acquiring and saving the state data of target resource objects in the first secure container through their drivers, the state data of non-target resource objects in the first secure container can be acquired and saved through container runtime components. Acquiring and saving the state data of non-target resource objects in the first secure container through container runtime components requires that the state data of the non-target resource objects in the first secure container be in a stable state, i.e., unchanged. Based on this, the first secure container can be paused through container runtime components. Pausing the first secure container mainly refers to pausing the operation of the guest operating system within the first secure container. Specifically, the container runtime component can first obtain the ID or name of the first secure container, and then, based on this identification information and the container pause command provided by the container runtime component, pause the operation of the first secure container.

[0060] After pausing the first secure container, the status data of non-target resource objects within the first secure container can be obtained through the container runtime component. This status data describes the working state of the non-target resource objects and may include at least one of the following: currently stored data, storage space information, runtime space information, internal register information, and configuration information. Register information describes the current state of registers, such as their value, ID, or type. Configuration information describes various parameters and settings of the non-target resource objects, such as CPU function switches, performance settings, or operating modes. After obtaining the status data of the non-target resource objects in the first secure container, this data can be migrated to the non-target resource objects in the second secure container. It should be noted that the number of non-target resource objects in the second secure container must be greater than or equal to the number of non-target resource objects in the first secure container that need to be migrated, to ensure successful migration of the status data of non-target resource objects from the first secure container to the second secure container.

[0061] In this embodiment, under the pass-through architecture between the target resource object and the secure container, the target resource object in the first secure container on the source node relies on driver management, while the non-target resource object does not. Considering the different characteristics of the target and non-target resource objects, different layers of components can work together to obtain the state data of the target and non-target resource objects in the first secure container through the driver of the target resource object and the container runtime component. This allows for a relatively accurate migration of the state data of the target and non-target resource objects to the second secure container on the target node. In this way, the rapid migration of workloads within the secure container can be effectively achieved through the cooperation of different layers of components, solving the problem of state migration for secure containers containing target resource objects that cannot be directly managed by the secure container or its cloud vendor.

[0062] The secure container migration method in this application embodiment is applicable to various scenarios, such as application upgrades, resource optimization, or application failures. It can efficiently migrate the workload of the secure container on the source node to the secure container on the target node using the above methods. Specifically, in application upgrade scenarios, a smooth transition between old and new versions is crucial. In resource optimization scenarios, migrating workloads can achieve a more even load distribution, avoid the formation of hotspot nodes, and improve the overall system stability and response speed. In application failure scenarios, when a node fails, services can be restored by migrating workloads to other unaffected nodes, ensuring data security.

[0063] In some alternative embodiments, the guest operating system of the first secure container includes a driver for the target resource object, which is used to interact with the target resource object.

[0064] Within the first secure container, applications running on the guest operating system can run in user space. In other words, user space refers to the environment in which applications run within the secure container, which can be understood as the location where applications run on the guest operating system. In this embodiment, the user space of the first secure container may include a runtime library for the target resource object. This runtime library is built upon the driver program of the target resource object and encapsulates the functionality provided by the driver. It serves as a bridge for interaction between the application and the driver program of the target resource object. That is, the runtime library of the target resource object can be used for interaction between the application and the driver program of the target resource object; the application can initiate various requests to the driver program of the target resource object through the runtime library. When an application initiates a request through the runtime library of the target resource object, the request can be translated into a call to the driver program of the target resource object.

[0065] Taking a GPU as the target resource object as an example, the GPU's runtime library can be CUDA (Compute Unified Device Architecture). CUDA encapsulates the functionality provided by the GPU. When an application sends a request through CUDA, the request can be translated into a call to the GPU driver. In other words, the application can use CUDA to call the GPU driver to interact with the GPU.

[0066] Based on this, step S1 in the aforementioned embodiments, "pausing the operation of the target resource object of the first security container through the driver of the target resource object," can be implemented based on either Implementation Method 1 or Implementation Method 2:

[0067] Implementation Method 1: Intercept access requests initiated by applications within the first security container using interception functions in the runtime library, thereby suspending the execution of the target resource object within the first security container. This access request is initiated by the application through library functions in the runtime library to the driver of the target resource object.

[0068] This embodiment does not limit the method of obtaining the interception function. In some exemplary embodiments, a function configuration interface can be provided to the user, and the interception function input by the user can be obtained in response to the user's configuration operation on the function configuration interface. Alternatively, a preset interception function can be obtained from the storage space corresponding to the first security container in a preset manner. This embodiment does not impose any restrictions.

[0069] This embodiment allows for the pre-addition of interceptor functions in the runtime library, but does not limit the specific implementation of these interceptor functions. Optionally, interceptor functions can be added to the runtime library code based on hook technology to intercept functions that need to be intercepted in the runtime library. Hook technology is used to intercept function behavior without modifying the original code.

[0070] Specifically, you can first select the target function to be intercepted from the library functions in the runtime library. The library functions refer to the set of functions provided by the runtime library. After selecting the target function, you can choose a hooking method, such as the LD_PRELOAD method or the function replacement method, and then use the selected hooking method to add the intercepted function to the runtime library code. The LD_PRELOAD method can load a custom dynamic link library by setting the LD_PRELOAD environment variable. This dynamic link library contains the intercepted function that replaces the original library function. The function replacement method can replace the original library function with the intercepted function by modifying the pointer to the library function.

[0071] Applications within the first secure container can initiate access requests to the driver of the target resource object through library functions in the runtime library. Interception functions in the runtime library can effectively intercept these driver access behaviors of applications within the first secure container, preventing the driver of the target resource object from being triggered by applications within the first secure container, thereby suspending the operation of the target resource object in the first secure container.

[0072] In this way, on the one hand, the execution of the target resource object of the first security container can be suspended by adding an interception function to the runtime library in the pre-processing stage without relying on the driver. Since the interception function can be written according to the actual design requirements, this method has a high degree of controllability.

[0073] Implementation Method Two: The driver program for the target resource object is invoked to send a pause command to the target resource object in the first security container, thereby pausing the operation of the target resource object in the first security container. Specifically, the driver program can obtain the identification information of the target resource object. This identification information is used to identify the target resource object. Then, the driver program can query the current state of the target resource object based on this identification information to ensure that it can be paused. Sending the pause command to the target resource object through the driver program can be implemented as a function call, such as calling `PauseDevice()` or a similar operation. `PauseDevice()` is a function used to pause or stop device operation. This method of invoking the driver program allows for a relatively quick way to pause the operation of the target resource object.

[0074] Through the above implementation methods one and two, the execution of the target resource object of the first security container can be suspended relatively efficiently by adding an interception function in the runtime library or by calling the driver.

[0075] After pausing the execution of the target resource object in the first security container through the driver of the target resource object, step S2 can be continued to obtain the status data of the target resource object in the first security container.

[0076] This application does not limit the method of obtaining the state data of the target resource object of the first security container. In some exemplary embodiments, it can be implemented based on the following steps S21-S22:

[0077] Step S21: Call the target application interface in the driver of the target resource object to obtain the video memory list and its corresponding video memory content of the target resource object in the first secure container. The target application interface refers to the interface used to manage video memory usage. The video memory list refers to the list of video memory regions allocated to different applications on the target resource object, which may include information about the video memory segments used by each application, such as the starting address, size, type, and other relevant information of the video memory segment. The starting address of the video memory segment refers to the starting physical address or virtual address of the video memory segment; the type of the video memory segment can be VRAM (a type of video memory segment) or WRAM (a type of video memory segment), etc. The video memory segment is used to store video memory content, which varies depending on the application running in the first secure container. When running an AI framework and AI applications in the first secure container, the video memory content may be various data related to machine learning models, etc. Other relevant information may include the status of the video memory segment, such as idle, in use, etc., and may also include the priority of the video memory segment, which is not limited in this embodiment.

[0078] Optionally, before obtaining the video memory list of the target resource object in the first security container, the video memory list of the target resource object can be determined in the following way: First, a proxy function can be added to the runtime library to proxy access requests initiated by applications in the first security container to the driver of the target resource object through library functions in the runtime library. The proxy function can be added to the runtime library based on hook technology; the specific implementation of this has been described in detail in the previous section "Adding Intercept Functions to the Runtime Library," and will not be repeated here. In this way, when an application in the first security container initiates an access request to the driver of the target resource object, it can be initiated by the proxy function instead of directly through the library functions in the runtime library. The proxy function can determine the request type of the access request, which may include memory allocation requests, initialization requests, and mode setting requests, etc. A memory allocation request may contain a list of video memory requested by the application from the target resource object. In the case of a memory allocation request, this access request can be initiated and the list of video memory requested by the application can be read from it, serving as the video memory list of the target resource object in the first security container.

[0079] Step S22: Call other application interfaces in the driver of the target resource object besides the target application interface to obtain other state data of the target resource object of the first security container. Other state data refers to state data other than the video memory list and its corresponding video memory content. There may be one or more other application interfaces, depending on the type and quantity of other state data. One application interface can be used to obtain one or more types of other state data; this embodiment does not impose any limitations. Other state data may include: internal register information, working status information, and configuration information.

[0080] The following example uses other application programming interfaces (APIs) implemented using the NVML library, a library for monitoring and managing target resource objects. Specifically, the name of the target resource object can be obtained by calling the API implemented based on the nvmlDeviceGetName() function in the driver of the target resource object; alternatively, the runtime space utilization rate of the target resource object can be obtained by calling the API implemented based on the nvmlDeviceGetUtilizationRates() function in the driver of the target resource object. This embodiment does not impose any limitations on this.

[0081] In this way, the state data of the target resource object in the first security container can be obtained relatively accurately by making interface calls to the application programming interface of the driver of the target resource object. Then, step S3 can be executed to create a second security container on the target node, and step S4 can be executed to migrate the state data of the target resource object in the first security container to the target resource object in the second security container.

[0082] This application does not limit the specific implementation of the state data migration method in step S4. In some exemplary embodiments, the non-target resource object of the first security container may include a regular network interface card (NIC). Based on this, the state data of the target resource object of the first security container can be copied to the target resource object of the second security container via TCP / IP (Transmission Control Protocol / Internet Protocol). In some exemplary embodiments, the non-target resource object of the first security container may include an RDMA NIC. Based on this, an RDMA operation can be issued via the RDMA NIC, and then the state data of the target resource object of the first security container can be copied to the target resource object of the second security container via the RDMA operation. The RDMA NIC supports RDMA technology, which is used for direct memory access between different nodes without CPU intervention, thereby improving data transmission efficiency and reducing transmission latency. Therefore, the RDMA operation issued by the RDMA NIC can efficiently migrate the state data of the target resource object of the first security container to the target resource object of the second security container. Furthermore, when the target resource object is implemented as a GPU, the process of migrating the state data of the target resource object through the RDMA network card can be called GDR (GPU DirectRDMA). That is, the state data is directly transmitted between the GPUs of the first and second security containers through the RDMA network, without the need for memory copying through the CPU, which can achieve high-speed transmission of GPU state data.

[0083] Correspondingly, one implementation of step S4, which migrates the state data of the target resource object of the first secure container to the target resource object of the second secure container, includes: instructing the creation of a first virtual machine in the second secure container and binding the target resource object of the second secure container to the first virtual machine, and migrating the state data of the target resource object of the first secure container to the target resource object bound to the first virtual machine; and instructing the creation of a second virtual machine in the second secure container and binding the non-target resource object of the second secure container to the second virtual machine, and binding the target resource object bound to the first virtual machine to the second virtual machine, so as to migrate the state data of the target resource object of the first secure container to the target resource object of the second secure container. Correspondingly, step S5 involves receiving the state data of the target resource object of the first secure container and storing the state data of the target resource object of the first secure container in the target resource object of the second secure container. Specifically, step S5 can be executed based on the following steps S51-52:

[0084] Step 51: According to the instruction information, create a first virtual machine in the second secure container, bind the target resource object of the second secure container to the first virtual machine, and migrate the state data of the target resource object of the first secure container to the target resource object bound to the first virtual machine. This instruction information comes from the container runtime component or management node on the source node and is used to instruct the creation of the first virtual machine in the second secure container, the binding of the target resource object of the second secure container to the first virtual machine, and the migration of the state data of the target resource object of the first secure container to the target resource object bound to the first virtual machine.

[0085] This embodiment does not limit the creation of the first virtual machine, which can be created using virtualization tools such as Kata Containers or QEMU (Quick EMUlator). QEMU is an open-source virtual machine monitor and emulator that allows multiple virtual machines to run simultaneously on a single host and provides management and control capabilities for these virtual machines. After creating the first virtual machine, a mapping relationship can be established between the target resource object of the second secure container and the first virtual machine. Then, based on this mapping relationship, the state data of the target resource object of the first secure container can be sent to the target resource object bound to the first virtual machine. In this way, the target resource object bound to the first virtual machine in the second secure container can carry the state data of the target resource object of the first secure container.

[0086] Step 52: According to the instructions, create a second virtual machine in the second secure container, bind the non-target resource objects of the second secure container to the second virtual machine, and bind the target resource objects bound to the first virtual machine to the second virtual machine, so as to migrate the state data of the target resource objects of the first secure container to the target resource objects of the second secure container. This instruction comes from the container runtime component or management node on the source node and instructs the creation of a second virtual machine in the second secure container, the binding of the non-target resource objects of the second secure container to the second virtual machine, and the rebinding of the target resource objects bound to the first virtual machine to the second virtual machine, so as to migrate the state data of the target resource objects of the first secure container to the target resource objects of the second secure container.

[0087] This embodiment does not limit the use of virtualization tools such as Kata Containers, QEMU, or Hypervisor to create the second virtual machine. After creating the second virtual machine, a mapping relationship can be established between the non-target resource objects of the second secure container and the second virtual machine. Furthermore, based on this mapping relationship, the state data of the non-target resource objects of the first secure container can be migrated to the non-target resource objects bound to the second secure container and the second virtual machine. Additionally, considering that both the first and second virtual machines run in the second secure container, the target resource objects bound to the first virtual machine can be bound to the second virtual machine, and the first virtual machine can be destroyed or paused to run the second virtual machine in the second secure container. Since the target resource objects in the second secure container are bound to the second virtual machine, it means that the state data of the target resource objects in the first secure container is migrated to the target resource objects bound to the second virtual machine in the second secure container.

[0088] In this way, on the one hand, a mapping relationship can be established between the target resource objects and non-target resource objects of the second secure container and the second virtual machine, thereby ensuring the consistency of resources between the second virtual machine and the second secure container. That is, the second virtual machine can access not only the target resource objects of the second secure container but also the non-target resource objects. On the other hand, by creating and destroying virtual machines, it can be ensured that only one virtual machine runs within the second secure container, thereby improving the isolation and security of the virtual machine and the correctness of the data.

[0089] In addition to the above embodiments, this application also provides an implementation method in which the state data of the target resource object in the first security container is stored in the target resource object in the second security container. For details, please refer to... Figure 2b Steps S23, S24, and S30 in the process. For example... Figure 2b The secure container migration method shown includes:

[0090] Step S21: During the operation of the first secure container, the operation of the target resource object of the first secure container is paused through the driver of the target resource object.

[0091] Step S22: Obtain the state data of the target resource object of the first security container through the driver of the target resource object.

[0092] Step S23: Instruct the creation of a third security container on the target node; the third security container includes the target resource object that depends on driver management.

[0093] Step S24: Migrate the state data of the target resource object in the first security container to the target resource object in the third security container.

[0094] Step S25: Receive the status data of the target resource object of the first security container and save the status data of the target resource object of the first security container in the target resource object of the third security container.

[0095] Step S26: Pause the operation of the first secure container through the container runtime component corresponding to the first secure container.

[0096] Step S27: Obtain the state data of the non-target resource object of the first security container through the container runtime component corresponding to the first security container.

[0097] Step S28: Instruct the creation of a second security container on the target node; the second security container includes non-target resource objects that are not dependent on driver management.

[0098] Step S29: Migrate the state data of the non-target resource object in the first security container to the non-target resource object in the second security container.

[0099] Step S30: Transfer the target resource object of the third security container to the second security container to migrate the workload in the first security container to the second security container.

[0100] For details regarding steps S21-S22, S26-S27, and S29, please refer to [link / reference needed]. Figure 2a The descriptions of the corresponding steps in the illustrated embodiments will not be repeated here.

[0101] In this embodiment, two security containers are created on the target node: a third security container and a second security container. The third security container includes the target resource object, and the second security container includes non-target resource objects. First, the state data of the target resource object in the first security container is stored in the target resource object of the third security container, and the state data of the non-target resource objects in the first security container is migrated to the non-target resource objects of the second security container. Then, the target resource object in the third security container is transferred to the second security container to migrate the workload in the first security container to the second security container. Specifically, transferring the target resource object from the third security container to the second security container means reattaching the target resource object mounted on the third security container to the second security container and removing the mounting relationship between the target resource object and the third security container.

[0102] Furthermore, in this embodiment, the order and timing of creating the second and third secure containers are not limited. They can be created in advance or in real-time when state data migration is required; there is no limitation on this, as long as the creation of the secure containers is completed before their use. Similarly, the third secure container can be created by the container runtime component on the source node instructing the target node to create it, or it can be created by the control node instructing the target node to create it; there is no limitation on this. Regardless of which object instructs the creation of the second and third secure containers, the creation process of the second and third secure containers, as well as the process of attaching relevant resource objects to the second or third secure containers, are all completed by the container runtime component on the target node. These specific processes are not limited or concerned in this embodiment; some existing technologies can be referred to, or a self-developed solution can be used.

[0103] In this way, a new security container can be created on the target node, so that the state data of the target resource object in the first security container can be saved to the target resource object in the second security container more efficiently via the new security container.

[0104] Further optional, such as Figure 2b As shown, after step S30, the following may also be included:

[0105] Step S31: Stop the first secure container from running; specifically, the first secure container can be stopped by the container runtime component corresponding to the first secure container on the source node. Stopping here means shutting down the first secure container.

[0106] Step S32: Stop the third security container from running; specifically, the third security container can be stopped by the container runtime component corresponding to the third security container on the target node. Stopping here means shutting down the third security container.

[0107] Step S33: Restore the operation of the second secure container through the container runtime component corresponding to the second secure container in the target node, and restore the operation of the target resource object through the driver of the target resource object. The driver of the target resource object resides in the guest operating system of the second secure container. Specifically, the container runtime component can call the driver of the target resource object to restore the operation of the target resource object through the driver. For details on restoring the operation of the target resource object, please refer to the descriptions in subsequent steps S11 and S12, which will not be elaborated here.

[0108] After migrating the state data of the target resource object of the first secure container to the target resource object of the second secure container based on the above embodiments, step S6 can be executed to pause the operation of the first secure container through the container runtime component. By pausing the operation of the first secure container, the state data of the non-target resource objects of the first secure container can be kept unchanged; in other words, pausing the operation of the first secure container aims to prevent the state data of the non-target resource objects from changing when step S7 is executed. The relevant content of this state data has been described in detail above and will not be repeated here.

[0109] This application does not limit the specific implementation of step S7, "obtaining the state data of the non-target resource objects of the first secure container through the container runtime component corresponding to the first secure container." In some exemplary embodiments, the container runtime component can obtain and save the state data of the non-target resource objects of the first secure container based on the state saving tool in the user space of the first secure container. Alternatively, in other exemplary embodiments, the user can manually save and restore the state data of the non-target resource objects of the first secure container. The container runtime component can respond to the user's save operation by obtaining and saving the state data of the non-target resource objects of the first secure container.

[0110] The first secure container state preservation tool is a secure container persistence tool implemented based on checkpoint-restore technology, a technique for real-time state preservation and restoration of containers. This technology allows a container to save its runtime state data in one location (called a checkpoint) and restore that state data in another location (called a restore). In short, the state preservation tool can be used to save the runtime state of a secure container and quickly restore it to that runtime state in subsequent processes. This embodiment does not limit the specific implementation of the state preservation tool. In some exemplary embodiments, the state preservation tool can be implemented as a CRIU (Checkpoint / Restore In Userspace) tool. A CRIU tool is a tool for implementing process state snapshots and restoration, which can be used to save the state data of resource objects in user space and restore that state data when needed.

[0111] Based on the above, the container runtime component can invoke a state saving tool, which can save the state data of non-target resource objects in the first secure container to the memory of the source node. Specifically, the container runtime component can invoke the state saving tool by sending an invocation command to it. The state saving tool can then take a state snapshot of the non-target resource objects in the first secure container to obtain the corresponding state data and save this state data to the memory of the source node.

[0112] In this way, the state data of non-target resource objects in the first security container can be obtained relatively efficiently based on the state preservation tool.

[0113] After obtaining the state data of the non-target resource object of the first secure container through the container runtime component, step S8 or step S28 can be executed to migrate the state data of the non-target resource object of the first secure container to the non-target resource object of the second secure container. In some exemplary embodiments, the non-target resource object of the first secure container may include a regular network interface card (NIC). Based on this, the state data of the non-target resource object of the first secure container can be copied to the non-target resource object of the second secure container via the regular NIC using TCP / IP. Optionally, if the non-target resource objects of the first and second secure containers contain RDMA NICs, the state data of the non-target resource object of the first secure container can be migrated to the non-target resource object of the second secure container via RDMA operations. Since RDMA operations can directly access memory between different nodes without CPU intervention, it is beneficial to improve data transmission efficiency and reduce transmission latency. Therefore, the state data of the non-target resource object of the first secure container can be migrated to the non-target resource object of the second secure container efficiently and quickly.

[0114] In some optional embodiments, after the target node receives the status data of the target resource object and non-target resource object of the first security container and saves the status data to the second security container, that is, after completing the migration of the workload of the first security container, the target node can further restore the working state of the second security container based on the status data received by the second security container.

[0115] This application does not limit the specific implementation of restoring the working state of the second safety container. In some exemplary embodiments, the working state of the second safety container can be restored based on the following steps S10-S13:

[0116] Step S10: Run the second security container created in the aforementioned step S3 or step S27.

[0117] Step S11: Restore the working state of the non-target resource object based on the state data in the non-target resource object of the second security container.

[0118] Step S12: Restore the working state of the target resource object based on the state data in the target resource object of the second security container.

[0119] In some optional embodiments, the user space of the second secure container may include a state recovery tool, which corresponds to the state saving tool in the user space and is also implemented based on checkpoint-restore technology. Based on the above, the container runtime component can invoke the state recovery tool by sending an invocation command to it. The state recovery tool can provide the state data of the non-target resource object in the second secure container to the non-target resource object, allowing the non-target resource object to restore its working state based on this state data. Alternatively, in other exemplary embodiments, the user can manually restore the state data of the non-target resource object in the second secure container. The container runtime component can respond to the user's restoration operation by adjusting the working state of the non-target resource object based on its state data.

[0120] In some optional embodiments, the second security container may include a driver for the target resource object. The state data of the target resource object may include a video memory list and its corresponding video memory content, as well as other state data, which will not be elaborated here. Based on this, the target application programming interface (API) in the driver of the target resource object can be invoked to provide the video memory list and its corresponding video memory content from the target resource object of the second security container to the target resource object of the second security container. Here, the target application programming interface refers to an interface used to manage video memory usage. The relevant content regarding the video memory list has been described in detail above and will not be repeated here.

[0121] Subsequently, other application programming interfaces (APIs) in the driver of the target resource object can be invoked to provide other state data from the target resource object in the second security container to the target resource object of the second security container, thereby restoring the working state of the target resource object. There can be one or more APIs, depending on the number and types of other state data. One API can be used to obtain one or more other state data types; this embodiment does not impose any limitations.

[0122] In this way, the target node can efficiently restore the working state of the second security container based on the received state data after completing the state data migration.

[0123] Based on the above embodiments, in addition to the source node and the target node, this embodiment may also include a management node for managing and controlling the source node and the target node. The management node can issue container migration tasks to the source node, instructing the migration of the workload of the first secure container on the source node to the second secure container on the target node. Optionally, the management node can respond to a task issuance event and issue a container migration task to the source node. The task issuance event can be implemented as detecting a fault in the source node, detecting a fault in the first secure container on the source node, or detecting that the workload of the first secure container on the source node exceeds a preset range. This preset range can be set to any range according to actual design requirements; this embodiment does not impose any limitations.

[0124] In this embodiment, the control node can promptly issue container migration tasks to the source node. The container migration task is used to instruct the workload of the first secure container on the source node to be migrated to the second secure container on the target node.

[0125] Following the above embodiments, the secure container migration method provided in this application can be applied to intelligent computing service scenarios. The intelligent computing service can be deployed as an application in the user space of the first secure container, as described in the above embodiments. Specifically, the user can deploy the first secure container carrying the intelligent computing service on the source node through a management node, and directly connect the GPU on the source node to the first secure container as the computing power resource for the intelligent computing service. In this scenario, the intelligent computing service in the first secure container runs on the GPU. During the operation of the intelligent computing service, the following situations may occur: the user needs to upgrade the intelligent computing service, or the intelligent computing service malfunctions, or the source node malfunctions. In these cases, the intelligent computing service needs to be migrated, i.e., the workload of the first secure container needs to be migrated. At this time, the management node can determine the target node to which the migration needs to be performed and issue a state migration instruction to the source node, indicating that the first secure container on the source node needs to be migrated to the second secure container on the target node. Optionally, the management node can notify the target node to create the second secure container, or the source node can notify the target node to create the second secure container; the second secure container can be created in advance or created in real time when state data migration is required. According to the state migration instruction, the source node executes the migration steps described in the above method embodiment to migrate the intelligent computing service from the first secure container of the source node to the second secure container of the target node. Then, based on the various state data migrated, the states of GPU, CPU, network, memory, etc. in the second secure container are restored to ensure that the states of GPU, CPU, storage, and network are consistent before and after the migration. The operation of the intelligent computing service can be restored in the second secure container, so that the intelligent computing service can continue to provide services to customers.

[0126] The intelligent computing service scenario is merely one application scenario of the secure container migration method provided in this application embodiment, and is not limited thereto. For example, the secure container migration method provided in this application embodiment can also be applied to the Function Compute service scenario, where the Function Compute service can be deployed as an application in the user space of the first secure container as described in the above embodiments. Function Compute provides a way to execute code on demand; users only need to write and upload function code without worrying about the maintenance and expansion of the underlying infrastructure. The migration process of the secure container in this Function Compute application scenario is the same as in the above embodiments and will not be described again.

[0127] For example, the secure container migration method provided in this application embodiment can also be applied to PAI (Platform for AI) scenarios. The AI ​​platform service can be deployed as an application in the user space of the first secure container, as described in the above embodiments. The AI ​​platform service is used for target users to build, train, deploy, and manage artificial intelligence and machine learning models. The migration process of the secure container in this PAI application scenario is the same as in the above embodiments and will not be repeated here.

[0128] Following the above embodiments, this application also provides a secure container migration method for migrating workloads in a first secure container on a source node. The first secure container includes a target resource object and a non-target resource object, wherein the target resource object is a pass-through device of the first secure container. Figure 3 As shown, the method includes:

[0129] Step 31: During the operation of the first secure container, the target resource object of the first secure container is paused through the driver of the target resource object, and the status data of the target resource object of the first secure container is obtained.

[0130] Step 32: Migrate the state data of the target resource object in the first security container to the target resource object in the second security container, which is a security container on the target node.

[0131] Step 33: Pause the operation of the first secure container by using the container runtime component corresponding to the first secure container, and obtain the status data of the non-target resource objects of the first secure container.

[0132] Step 34: Migrate the state data of the non-target resource objects in the first security container to the non-target resource objects in the second security container, so as to migrate the workload in the first security container to the second security container.

[0133] Optionally, the first secure container includes a guest operating system, which includes a driver for the target resource object. The user space of the first secure container includes a runtime library for the target resource object. Pausing the execution of the target resource object in the first secure container via the driver includes: intercepting access requests initiated by applications in the first secure container using interception functions in the runtime library to pause the execution of the target resource object; the access request is initiated by the application to the driver for the target resource object through library functions in the runtime library; or, calling the driver for the target resource object to send a pause command to the target resource object in the first secure container to pause the execution of the target resource object.

[0134] Optionally, obtaining the state data of the target resource object of the first security container through the driver of the target resource object includes: calling the target application interface in the driver of the target resource object to obtain the video memory list and its corresponding video memory content of the target resource object of the first security container; calling other application interfaces in the driver of the target resource object other than the target application interface to obtain other state data of the target resource object of the first security container, wherein the other state data refers to state data other than the video memory list and its corresponding video memory content.

[0135] Optionally, the user space of the first secure container includes a runtime library for the target resource object. The method further includes: using a proxy function in the runtime library to proxy access requests initiated by the application in the first secure container, and, if the access request is a memory allocation request, obtaining a list of video memory requested by the application as the video memory list of the target resource object in the first secure container; the access request is initiated by the application to the driver of the target resource object through a library function in the runtime library.

[0136] Optionally, the user space of the first secure container includes a state saving tool. Through the container runtime component corresponding to the first secure container, the first secure container is paused, and the state data of the non-target resource objects of the first secure container is obtained. This includes: the container runtime component pausing the first secure container to keep the state data of the non-target resource objects of the first secure container unchanged; and the container runtime component calling the state saving tool to obtain the state data of the non-target resource objects of the first secure container and saving it to the memory of the source node.

[0137] Optionally, creating a second secure container on the target node and migrating the state data of the target resource object in the first secure container to the target resource object in the second secure container includes: creating a third secure container on the target node and migrating the state data of the target resource object in the first secure container to the target resource object in the third secure container; creating a second secure container on the target node and transferring the target resource object in the third secure container to the second secure container to migrate the state data of the target resource object in the first secure container to the target resource object in the second secure container; or creating a first virtual machine in the second secure container, binding the target resource object of the second secure container to the first virtual machine, and migrating the state data of the target resource object of the first secure container to the target resource object bound to the first virtual machine; or creating a second virtual machine in the second secure container, binding the non-target resource object of the second secure container to the second virtual machine, and binding the target resource object bound to the first virtual machine to the second virtual machine to migrate the state data of the target resource object of the first secure container to the target resource object in the second secure container.

[0138] Further optionally, the non-target resource object of the first security container includes an RDMA network interface card; migrating the state data of the target resource object of the first security container to the target resource object of the second security container includes: copying the state data of the target resource object of the first security container to the target resource object of the second security container through RDMA operation; migrating the state data of the non-target resource object of the first security container to the non-target resource object of the second security container includes: copying the state data of the non-target resource object of the first security container to the non-target resource object of the second security container through RDMA operation.

[0139] Further optionally, the method further includes: receiving a container migration task issued by a management node, the container migration task being used to instruct the migration of the workload of a first secure container on the source node to a second secure container on the target node.

[0140] The detailed implementation methods and beneficial effects of each step in this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0141] Following the above embodiments, this application also provides a secure container migration method for migrating the workload of a first secure container on a source node, wherein a second secure container is created on the target node, and the second secure container includes target resource objects that depend on driver management and non-target resource objects that do not depend on driver management; such as Figure 4 As shown, the method includes:

[0142] Step 42: Receive the status data of the target resource object in the first security container, and save the status data of the target resource object in the first security container in the target resource object of the second security container;

[0143] Step 43: Receive the status data of the non-target resource object in the first security container, and save the status data of the non-target resource object in the first security container in the non-target resource object of the second security container.

[0144] Further optional, such as Figure 4 As shown, before step 42, the method further includes: step 41, creating a second security container on the target node. The second security container includes target resource objects that depend on driver management and non-target resource objects that do not depend on driver management. It should be noted that this embodiment does not limit the timing of creating the second security container. Figure 4 The example shown is for illustrative purposes only.

[0145] Further optionally, the method further includes: running a second security container; restoring the working state of the non-target resource object based on the state data in the non-target resource object of the second security container; and restoring the working state of the target resource object based on the state data in the target resource object of the second security container.

[0146] Further optionally, the user space of the second security container includes: a state recovery tool, which restores the working state of the non-target resource object based on the state data in the non-target resource object of the second security container, including: calling the state recovery tool to provide the state data in the non-target resource object of the second security container to the non-target resource object to restore the working state of the non-target resource object.

[0147] Optionally, the second secure container includes a driver for the target resource object, and the state data of the target resource object includes a video memory list and its corresponding video memory content, as well as other state data. Restoring the working state of the target resource object based on the state data in the target resource object of the second secure container includes: calling a target application programming interface (API) in the driver of the target resource object to provide the video memory list and its corresponding video memory content in the target resource object of the second secure container to the target resource object of the second secure container; and calling other application programming interfaces (APIs) in the driver of the target resource object other than the target API to provide other state data in the target resource object of the second secure container to the target resource object of the second secure container, thereby restoring the working state of the target resource object. The other state data refers to state data other than the video memory list and its corresponding video memory content.

[0148] Optionally, storing the state data of the target resource object of the first security container in the target resource object of the second security container includes: migrating the state data of the target resource object of the first security container to the target resource object of the third security container, wherein the third security container is a security container on the target node; and, if the second security container is created, transferring the target resource object of the third security container to the second security container to migrate the state data of the target resource object of the first security container to the target resource object of the second security container.

[0149] Further optionally, before creating the second secure container on the target node, the method further includes: creating a third secure container on the target node.

[0150] Optionally, storing the state data of the target resource object of the first secure container in the target resource object of the second secure container includes: creating a first virtual machine in the second secure container, binding the target resource object of the second secure container to the first virtual machine, and migrating the state data of the target resource object of the first secure container to the target resource object bound to the first virtual machine; creating a second virtual machine in the second secure container, binding the non-target resource object of the second secure container to the second virtual machine, and binding the target resource object bound to the first virtual machine to the second virtual machine, so as to migrate the state data of the target resource object of the first secure container to the target resource object of the second secure container.

[0151] The detailed implementation methods and beneficial effects of each step in this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0152] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 31 to 34 can be the first device; or the execution subject of steps 31 and 32 can be the first device, and the execution subject of steps 33 and 34 can be the second device; and so on.

[0153] Furthermore, in some of the processes described in the above embodiments and accompanying drawings, multiple operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 31, 32, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0154] Figure 5 This is a schematic diagram of a secure container migration apparatus provided as another exemplary embodiment of this application, used to migrate workloads in a first secure container on a source node. The first secure container includes a target resource object and a non-target resource object, where the target resource object is a pass-through device of the first secure container. Figure 5 As shown, the device includes:

[0155] The first pause module 501 is used to pause the operation of the target resource object of the first secure container during the operation of the first secure container by means of the driver of the target resource object, and to obtain the status data of the target resource object of the first secure container; the first migration module 502 is used to create a second secure container on the target node and migrate the status data of the target resource object of the first secure container to the target resource object of the second secure container; the second pause module 503 is used to pause the operation of the first secure container by means of the container runtime component corresponding to the first secure container, and to obtain the status data of the non-target resource objects of the first secure container; the second migration module 504 is used to migrate the status data of the non-target resource objects of the first secure container to the non-target resource objects of the second secure container, so as to migrate the workload in the first secure container to the second secure container.

[0156] Optionally, the first secure container includes a guest operating system, which includes a driver for the target resource object. The user space of the first secure container includes a runtime library for the target resource object. The first pause module 501 pauses the runtime of the target resource object in the first secure container through the driver of the target resource object. Specifically, it is used to: intercept access requests initiated by applications in the first secure container using interception functions in the runtime library to pause the execution of the target resource object in the first secure container; the access request is initiated by the application through library functions in the runtime library to the driver of the target resource object; or, call the driver of the target resource object to send a pause command to the target resource object in the first secure container to pause the execution of the target resource object in the first secure container.

[0157] Further optionally, when the first pause module 501 obtains the status data of the target resource object of the first secure container through the driver of the target resource object, it is specifically used to: call the target application interface in the driver of the target resource object to obtain the video memory list and its corresponding video memory content of the target resource object of the first secure container; call other application interfaces in the driver of the target resource object other than the target application interface to obtain other status data of the target resource object of the first secure container, wherein the other status data refers to status data other than the video memory list and its corresponding video memory content.

[0158] Optionally, the user space of the first secure container includes a runtime library for the target resource object. The first pause module 501 is further configured to: proxy access requests initiated by applications in the first secure container using proxy functions in the runtime library, and, if the access request is a memory allocation request, obtain a list of video memory requested by the application as the video memory list of the target resource object in the first secure container. The access request is initiated by the application to the driver of the target resource object through library functions in the runtime library.

[0159] Optionally, the user space of the first secure container includes a state saving tool. When the second pause module 503 pauses the operation of the first secure container through the container runtime component corresponding to the first secure container and obtains the state data of the non-target resource objects of the first secure container, it is specifically used for: the container runtime component pausing the operation of the first secure container to keep the state data of the non-target resource objects of the first secure container unchanged; and the container runtime component calling the state saving tool to obtain the state data of the non-target resource objects of the first secure container and saving it to the memory of the source node.

[0160] Optionally, when the first migration module 502 creates a second secure container on the target node and migrates the state data of the target resource object in the first secure container to the target resource object in the second secure container, it is specifically used for: creating a third secure container on the target node and migrating the state data of the target resource object in the first secure container to the target resource object in the third secure container; creating a second secure container on the target node and transferring the target resource object in the third secure container to the second secure container to migrate the state data of the target resource object in the first secure container to the target resource object in the second secure container; or creating a first virtual machine in the second secure container, binding the target resource object of the second secure container to the first virtual machine, and migrating the state data of the target resource object of the first secure container to the target resource object bound to the first virtual machine; or creating a second virtual machine in the second secure container, binding the non-target resource object of the second secure container to the second virtual machine, and binding the target resource object bound to the first virtual machine to the second virtual machine to migrate the state data of the target resource object of the first secure container to the target resource object in the second secure container.

[0161] Optionally, the non-target resource object of the first security container includes an RDMA network interface card; when the first migration module 502 migrates the state data of the target resource object of the first security container to the target resource object of the second security container, it is specifically used to: copy the state data of the target resource object of the first security container to the target resource object of the second security container through RDMA operation; when the second migration module 504 migrates the state data of the non-target resource object of the first security container to the non-target resource object of the second security container, it is specifically used to: migrate the state data of the non-target resource object of the first security container to the non-target resource object of the second security container through RDMA operation.

[0162] Further optionally, the second migration module 504 is also configured to: receive a container migration task issued by the control node, the container migration task being used to instruct the migration of the workload of the first secure container on the source node to the second secure container on the target node.

[0163] Figure 6 This is a schematic diagram of another secure container migration apparatus provided as a further exemplary embodiment of this application, used to migrate the workload of a first secure container on a source node. This secure container migration apparatus can be implemented in a target node, wherein a second secure container is created on the target node, and the second secure container includes a target resource object that depends on driver management and non-target resource objects that do not depend on driver management. Figure 6 As shown, the device includes:

[0164] The first storage module 602 is used to receive the status data of the target resource object of the first security container and store the status data of the target resource object of the first security container in the target resource object of the second security container; the second storage module 603 is used to receive the status data of the non-target resource object of the first security container and store the status data of the non-target resource object of the first security container in the non-target resource object of the second security container.

[0165] Further optional, such as Figure 6 As shown, the device also includes a creation module 601 for creating a second security container on the target node.

[0166] Further optionally, the creation module 601 is also configured to: run a second security container; restore the working state of a non-target resource object based on the state data in the non-target resource object of the second security container; and restore the working state of a target resource object based on the state data in the target resource object of the second security container.

[0167] Further optionally, the user space of the second security container includes: a state recovery tool. When the creation module 601 restores the working state of the non-target resource object based on the state data in the non-target resource object of the second security container, it is specifically used to: call the state recovery tool to provide the state data in the non-target resource object of the second security container to the non-target resource object to restore the working state of the non-target resource object.

[0168] Optionally, the second secure container includes a driver for the target resource object, and the state data of the target resource object includes a video memory list and its corresponding video memory content, as well as other state data. When the creation module 601 restores the working state of the target resource object based on the state data in the target resource object of the second secure container, it is specifically used to: call the target application programming interface in the driver of the target resource object to provide the video memory list and its corresponding video memory content in the target resource object of the second secure container to the target resource object of the second secure container; call other application programming interfaces in the driver of the target resource object besides the target application programming interface to provide other state data in the target resource object of the second secure container to the target resource object of the second secure container to restore the working state of the target resource object, wherein the other state data refers to state data other than the video memory list and its corresponding video memory content.

[0169] Optionally, the first storage module 602 stores the state data of the target resource object of the first security container in the target resource object of the second security container, including: migrating the state data of the target resource object of the first security container to the target resource object of the third security container, wherein the third security container is a security container on the target node; and, if the second security container is created, transferring the target resource object of the third security container to the second security container to migrate the state data of the target resource object of the first security container to the target resource object of the second security container.

[0170] Further optionally, before creating the second security container on the target node, the creation module 601 is also used to: create a third security container on the target node.

[0171] Optionally, when the first storage module 602 stores the state data of the target resource object of the first security container in the target resource object of the second security container, it is specifically used to: create a first virtual machine in the second security container, bind the target resource object of the second security container to the first virtual machine, and migrate the state data of the target resource object of the first security container to the target resource object bound to the first virtual machine; create a second virtual machine in the second security container, bind the non-target resource object of the second security container to the second virtual machine, and rebind the target resource object bound to the first virtual machine to the second virtual machine, so as to migrate the state data of the target resource object of the first security container to the target resource object of the second security container.

[0172] The above describes the internal functions and structure of the secure container migration device, such as... Figure 7 As shown, in practice, the secure container migration device can be implemented as a computer device, which can be implemented as the source node in the above embodiments, including: memory 701, processor 702 and communication component 703.

[0173] Memory 701 is used to store computer programs and can be configured to store various other data to support operation on the computer device. Examples of this data include instructions for any application or method operating on the computer device, contact data, phone book data, messages, pictures, videos, etc. Optionally, memory 701 stores program code related to the first secure container, as well as program code related to the container runtime components.

[0174] In some embodiments, processor 701, coupled to memory 702, is configured to execute a computer program (here, the computer program mainly refers to program code related to the container runtime component on the source node) in memory 702, for the following purposes: during the operation of the first secure container, by means of the driver of the target resource object, suspending the operation of the target resource object of the first secure container and obtaining the status data of the target resource object of the first secure container; instructing the creation of a second secure container on the target node, and migrating the status data of the target resource object of the first secure container to the target resource object of the second secure container; by means of the container runtime component corresponding to the first secure container, suspending the operation of the first secure container and obtaining the status data of the non-target resource objects of the first secure container; migrating the status data of the non-target resource objects of the first secure container to the non-target resource objects of the second secure container, so as to migrate the workload in the first secure container to the second secure container.

[0175] Optionally, the first secure container includes a guest operating system, which includes a driver for the target resource object. The user space of the first secure container includes a runtime library for the target resource object. The processor 701, through the driver for the target resource object, suspends the runtime of the target resource object in the first secure container by: adding an interception function to the runtime library to intercept access requests initiated by applications in the first secure container through library functions in the runtime library to the driver for the target resource object, thereby suspending the execution of the target resource object in the first secure container; or, calling the driver for the target resource object to send a pause command to the target resource object in the first secure container, thereby suspending the execution of the target resource object in the first secure container.

[0176] Further optionally, when the processor 701 obtains the status data of the target resource object of the first secure container through the driver of the target resource object, it is specifically used to: call the target application interface in the driver of the target resource object to obtain the video memory list and its corresponding video memory content of the target resource object of the first secure container; call other application interfaces in the driver of the target resource object other than the target application interface to obtain other status data of the target resource object of the first secure container, wherein the other status data refers to status data other than the video memory list and its corresponding video memory content.

[0177] Further optionally, the user space of the first secure container includes a runtime library of the target resource object, and the processor 701 is further configured to: add proxy functions to the runtime library to proxy access requests initiated by the application in the first secure container to the driver of the target resource object through library functions in the runtime library, and, if the access request is a memory allocation request, obtain the list of video memory requested by the application as the list of video memory of the target resource object of the first secure container.

[0178] Optionally, the user space of the first secure container includes a state saving tool. When the processor 701 pauses the operation of the first secure container through the container runtime component corresponding to the first secure container and obtains the state data of the non-target resource objects of the first secure container, it is specifically used for: the container runtime component pausing the operation of the first secure container to keep the state data of the non-target resource objects of the first secure container unchanged; and the container runtime component calling the state saving tool to save the state data of the non-target resource objects of the first secure container to the memory of the source node.

[0179] Further optionally, when the processor 701 creates a second secure container on the target node and migrates the state data of the target resource object of the first secure container to the target resource object of the second secure container, it is specifically used to: instruct the creation of a third secure container on the target node and migrate the state data of the target resource object of the first secure container to the target resource object of the third secure container; instruct the creation of a second secure container on the target node and transfer the target resource object of the third secure container to the second secure container to migrate the state data of the target resource object of the first secure container to the target resource object of the second secure container; or instruct the creation of a first virtual machine in the second secure container, bind the target resource object of the second secure container to the first virtual machine, and migrate the state data of the target resource object of the first secure container to the target resource object bound to the first virtual machine; instruct the creation of a second virtual machine in the second secure container, bind the non-target resource object of the second secure container to the second virtual machine, and bind the target resource object bound to the first virtual machine to the second virtual machine to migrate the state data of the target resource object of the first secure container to the target resource object of the second secure container.

[0180] Further optionally, the non-target resource object of the first security container includes an RDMA network card; when the processor 701 migrates the state data of the target resource object of the first security container to the target resource object of the second security container, it is specifically used to: copy the state data of the target resource object of the first security container to the target resource object of the second security container through RDMA operation; when the processor 701 migrates the state data of the non-target resource object of the first security container to the non-target resource object of the second security container, it is specifically used to: migrate the state data of the non-target resource object of the first security container to the non-target resource object of the second security container through RDMA operation.

[0181] Further optionally, the processor 701 is also configured to: receive a container migration task issued by the management node, the container migration task being used to instruct the migration of the workload of the first secure container on the source node to the second secure container on the target node.

[0182] In other embodiments, processor 701, coupled to memory 702, is configured to execute a computer program in memory 702 for: receiving state data of a target resource object of a first security container and storing the state data of the target resource object of the first security container in a target resource object of a second security container, the second security container being a security container on a target node; receiving state data of a non-target resource object of the first security container and storing the state data of the non-target resource object of the first security container in a non-target resource object of the second security container.

[0183] Further optionally, the processor 701 is also configured to: create a second security container on the target node, the second security container including a target resource object that depends on driver management and a non-target resource object that does not depend on driver management.

[0184] Further optionally, the processor 701 is also configured to: run a second security container; restore the working state of the non-target resource object based on the state data in the non-target resource object of the second security container; and restore the working state of the target resource object based on the state data in the target resource object of the second security container.

[0185] Further optionally, the user space of the second security container includes: a state recovery tool. When the processor 701 restores the working state of the non-target resource object based on the state data in the non-target resource object of the second security container, it is specifically used to: call the state recovery tool to provide the state data in the non-target resource object of the second security container to the non-target resource object to restore the working state of the non-target resource object.

[0186] Optionally, the second secure container includes a driver for the target resource object, and the state data of the target resource object includes a video memory list and its corresponding video memory content, as well as other state data. When the processor 701 restores the working state of the target resource object based on the state data in the target resource object of the second secure container, it is specifically configured to: call the target application programming interface in the driver of the target resource object to provide the video memory list and its corresponding video memory content in the target resource object of the second secure container to the target resource object of the second secure container; call other application programming interfaces in the driver of the target resource object besides the target application programming interface to provide other state data in the target resource object of the second secure container to the target resource object of the second secure container, so as to restore the working state of the target resource object, wherein the other state data refers to state data other than the video memory list and its corresponding video memory content.

[0187] Further optionally, when the processor 701 stores the state data of the target resource object of the first security container in the target resource object of the second security container, it is specifically used to: migrate the state data of the target resource object of the first security container to the target resource object of the third security container, wherein the third security container is a security container on the target node; and when the second security container is created, transfer the target resource object of the third security container to the second security container to migrate the state data of the target resource object of the first security container to the target resource object of the second security container.

[0188] Further optionally, before the processor 701 creates the second secure container on the target node, it also includes creating a third secure container on the target node.

[0189] Further optionally, when the processor 701 stores the state data of the target resource object of the first security container in the target resource object of the second security container, it is specifically used for: creating a first virtual machine in the second security container, binding the target resource object of the second security container to the first virtual machine, and migrating the state data of the target resource object of the first security container to the target resource object bound to the first virtual machine; creating a second virtual machine in the second security container, binding the non-target resource object of the second security container to the second virtual machine, and binding the target resource object bound to the first virtual machine to the second virtual machine, so as to migrate the state data of the target resource object of the first security container to the target resource object of the second security container.

[0190] Furthermore, such as Figure 7 As shown, the computer device also includes other components such as a display 704, a power supply component 705, and an audio component 706. Figure 7 The diagram only shows some components and does not mean that the computer device includes only these components. Figure 7 The components shown. Additionally... Figure 7 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the product form of the computer device. The computer device in this embodiment can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or a server-side device such as a conventional server, cloud server, or server array. If the computer device in this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include... Figure 7 The components within the dashed box; if the computer device in this embodiment is implemented as a conventional server, cloud server, or server array, etc., then it may not include... Figure 7 The component within the dashed box.

[0191] This application also provides a cloud computing system, including: a source node and a target node; the source node and the target node cooperate with each other to migrate the workload in a first secure container on the source node to a second secure container on the target node; wherein, the process of cooperation between the source node and the target node and the working process of each node during the cooperation can be referred to the foregoing embodiments, and will not be repeated here.

[0192] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the above method embodiments.

[0193] Accordingly, this application also provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps in the above method embodiments.

[0194] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0195] The aforementioned communication components are configured to facilitate wired or wireless communication between the device containing the communication components and other devices. The device containing the communication components can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication components receive broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication components also include a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), and other technologies.

[0196] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0197] The aforementioned power supply components provide power to various components of the device in which they reside. The power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

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

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

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

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

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

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

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

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

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

[0207] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A secure container migration method, characterized by, A method for migrating a workload in a first secure container on a source node, the first secure container comprising target resource objects and non-target resource objects, the target resource objects being pass-through devices of the first secure container, the method comprising: suspending, by a driver of the target resource objects, running of the target resource objects of the first secure container and obtaining state data of the target resource objects of the first secure container during running of the first secure container; migrating the state data of the target resource objects of the first secure container to target resource objects of a second secure container, the second secure container being a secure container on a target node; suspending, by a container runtime component corresponding to the first secure container, running of the first secure container and obtaining state data of the non-target resource objects of the first secure container; migrating the state data of the non-target resource objects of the first secure container to non-target resource objects of the second secure container to migrate the workload in the first secure container to the second secure container.

2. The method of claim 1, wherein, The first secure container comprises a driver of the target resource objects in a guest operating system of the first secure container and a runtime library of the target resource objects in a user space of the first secure container, and suspending, by the driver of the target resource objects, running of the target resource objects of the first secure container comprises: intercepting, by an intercept function in the runtime library, an access request initiated by an application in the first secure container to suspend running of the target resource objects of the first secure container, the access request being initiated by the application to the driver of the target resource objects through a library function in the runtime library; or calling the driver of the target resource objects to send a suspension command to the target resource objects of the first secure container to suspend running of the target resource objects of the first secure container. Obtaining, by the driver of the target resource objects, the state data of the target resource objects of the first secure container comprises:

3. The method of claim 1, wherein, calling a target application programming interface in the driver of the target resource objects to obtain a list of video memory and corresponding video memory content of the target resource objects of the first secure container; and calling other application programming interfaces in the driver of the target resource objects other than the target application programming interface to obtain other state data of the target resource objects of the first secure container, the other state data being state data other than the list of video memory and the corresponding video memory content. The first secure container comprises the runtime library of the target resource objects in the user space of the first secure container, and the method further comprises:

4. The method of claim 1, wherein, using a proxy function in the runtime library to proxy an access request initiated by an application in the first secure container, and obtaining a list of video memory applied by the application as the list of video memory of the target resource objects of the first secure container in a case where the access request is a memory allocation request, the access request being initiated by the application to the driver of the target resource objects through a library function in the runtime library. ​ 5. The method of claim 1, wherein, The state saving tool is included in a user space of the first secure container, the first secure container is suspended by a container runtime component corresponding to the first secure container, and state data of a non-target resource object of the first secure container is acquired. The container runtime component suspends the first secure container to keep the state data of the non-target resource object of the first secure container unchanged. The container runtime component calls the state saving tool to acquire the state data of the non-target resource object of the first secure container and save the state data into the memory of the source node.

6. The method of claim 1, wherein, Indicating to create a second secure container on the target node, migrating the state data of the target resource object of the first secure container into a target resource object of the second secure container, including: Indicating to create a third secure container on the target node, migrating the state data of the target resource object of the first secure container into a target resource object of the third secure container; Indicating to create a second secure container on the target node, migrating the target resource object of the third secure container to the second secure container to migrate the state data of the target resource object of the first secure container into a target resource object of the second secure container; Or Indicating to create a first virtual machine in the second secure container, binding the target resource object of the second secure container with the first virtual machine, and migrating the state data of the target resource object of the first secure container into the target resource object bound with the first virtual machine; Indicating to create a second virtual machine in the second secure container, binding the non-target resource object of the second secure container with the second virtual machine, and binding the target resource object bound with the first virtual machine with the second virtual machine to migrate the state data of the target resource object of the first secure container into the target resource object of the second secure container.

7. The method according to any one of claims 1 to 6, characterized in that, The non-target resource object of the first secure container includes a remote direct data access network card; Migrating the state data of the target resource object of the first secure container into the target resource object of the second secure container includes copying the state data of the target resource object of the first secure container into the target resource object of the second secure container through a remote direct data access operation; Migrating the state data of the non-target resource object of the first secure container into the non-target resource object of the second secure container includes copying the state data of the non-target resource object of the first secure container into the non-target resource object of the second secure container through a remote direct data access operation.

8. The method according to any one of claims 1 to 6, characterized in that, Further comprising: Receiving a container migration task issued by a management node, the container migration task being used to indicate to migrate a workload of a first secure container on a source node to a second secure container on a target node.

9. A secure container migration method, characterized by, A method for migrating a workload of a first secure container on a source node, a second secure container is created on a target node, the second secure container includes a target resource object managed by a dependency driver and a non-target resource object not managed by the dependency driver; the method comprises: receiving state data of a target resource object of the first secure container, and saving the state data of the target resource object of the first secure container in a target resource object of the second secure container; receiving state data of a non-target resource object of the first secure container, and saving the state data of the non-target resource object of the first secure container in a non-target resource object of the second secure container.

10. The method of claim 9, wherein, Further comprising: running the second secure container; restoring a working state of the non-target resource object according to the state data in the non-target resource object of the second secure container; restoring a working state of the target resource object according to the state data in the target resource object of the second secure container.

11. The method of claim 10, wherein, the second secure container comprises a driver of the target resource object, and the state data of the target resource object comprises a video memory list and corresponding video memory content thereof and other state data; restoring a working state of the target resource object according to the state data in the target resource object of the second secure container, comprises: calling a target application program interface in the driver of the target resource object, and providing the video memory list and corresponding video memory content thereof in the target resource object of the second secure container to the target resource object of the second secure container; calling other application program interfaces in the driver of the target resource object except the target application program interface, and providing other state data in the target resource object of the second secure container to the target resource object of the second secure container to restore the working state of the target resource object, the other state data referring to state data except the video memory list and corresponding video memory content thereof.

12. The method according to any one of claims 9-11, characterized in that, saving the state data of the target resource object of the first secure container in the target resource object of the second secure container, comprises: migrating the state data of the target resource object of the first secure container to a target resource object of a third secure container, the third secure container being a secure container on the target node; in a case where the second secure container is created, transferring the target resource object of the third secure container to the second secure container to migrate the state data of the target resource object of the first secure container to the target resource object of the second secure container.

13. A computer device, comprising: The source node can be implemented, and the source node comprises a host computer, the host computer deploying a first secure container and a container runtime component, the first secure container comprising a target resource object and a non-target resource object, the target resource object being a pass-through device of the first secure container, wherein the container runtime component is configured to perform steps in the method of any one of claims 1-8.

14. A computer device, comprising: comprising: a memory and a processor; the memory is configured to store a computer program, and the processor is coupled to the memory and configured to execute the computer program in the memory to implement steps in the method of any one of claims 1-8 and claims 9-12.

15. A computer-readable storage medium, characterized in that, When the computer program is executed by a processor, the processor is enabled to implement the steps in the method of any of claims 1-8 and 9-12.

16. A computer program product, characterised in that, comprising computer program / instructions which, when executed by a processor, perform the steps in the method of any of claims 1-8 and 9-12.

17. A cloud computing system, characterized by comprising: a source node for performing the method of any of claims 1-8 and a target node for performing the method of any of claims 9-12; the source node and the target node cooperating with each other to migrate a workload in a first secure container on the source node to a second secure container on the target node.

Images