Container configuration method and related device

Abstract

The invention provides a container configuration method and a related device thereof. The container configuration method is applied to a container cloud, the container cloud comprises a computing node and a computing device, and the container configuration method comprises the steps that in response to the fact that a process in a second container ends calling of a target computing device, the computing node destroys the operating environment of the second container, and the target computing device is called; the occupied computing resources of the target computing device are released; in response to a deployment instruction of a first container, the computing node obtains a target service packet of the first container; and the computing node loads the target service packet of the first container to a target computing device, and the first container can access the target computing device, so that the target computing device installs the target service packet of the first container and starts a service process of the first container. Through the container configuration method, the cross use mode of the computing equipment is simplified, and the utilization efficiency of computing resources in the container cloud is improved.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a container configuration method and related apparatus. Background Technology

[0002] Currently, GPUs (Graphics Processing Units) on container cloud platforms are centrally managed and allocated by the container cloud, which in turn provides them to different business teams. These different teams have their own customized needs when using GPUs. Based on this GPU usage scenario, the following problems exist:

[0003] Currently, each business team uses its own customized file system based on its specific business needs when using GPUs. Each time the GPU is used, it needs to load this customized file system. As a result, when different business teams share the same GPU, they need to switch the file system on the GPU. However, this switching operation is very cumbersome, requiring manual execution of relevant commands on the physical machine where the GPU is located, and a restart of the physical machine is also necessary. Summary of the Invention

[0004] To address the aforementioned technical problems, this application proposes a container configuration method and related apparatus.

[0005] To address the aforementioned technical problems, this application proposes a container configuration method applied to a container cloud, wherein the container cloud includes compute nodes and compute devices; the container configuration method includes:

[0006] In response to the termination of the process call to the target computing device within the second container, the computing node destroys the runtime environment of the second container and releases the computing resources of the target computing device it occupies.

[0007] In response to the deployment command of the first container, the compute node obtains the target service package of the first container;

[0008] The computing node loads the target service package of the first container into the target computing device, wherein the first container can access the target computing device to allow the target computing device to install the target service package of the first container and start the service process of the first container.

[0009] To address the aforementioned technical problems, this application also proposes a computing node, which includes a memory and a processor coupled to the memory;

[0010] The memory is used to store program data, and the processor is used to execute the program data to implement the container configuration method described above.

[0011] To address the aforementioned technical problems, this application also proposes a container configuration method applied to a container cloud, wherein the container cloud includes compute nodes and compute devices; the container configuration method includes:

[0012] In response to the termination of the process call to the target computing device within the second container, the target computing device performs an unloading operation of the target service package of the second container;

[0013] In response to the deployment command of the first container, the target computing device obtains the target service package of the first container through the computing node;

[0014] The target computing device installs the target service package of the first container and starts the service process of the first container.

[0015] To address the aforementioned technical problems, this application also proposes a computing device, which includes a memory and a processor coupled to the memory;

[0016] The memory is used to store program data, and the processor is used to execute the program data to implement the container configuration method described above.

[0017] To address the aforementioned technical problems, this application also proposes a computer storage medium for storing program data, which, when executed by a computer, is used to implement the aforementioned container configuration method.

[0018] Compared with existing technologies, this application responds to the termination of the process call to the target computing device within the second container by destroying the runtime environment of the second container and releasing the computing resources occupied by the target computing device. Then, the computing node obtains the target service package of the first container; the computing node loads the target service package onto the target computing device; the target computing device installs the target service package and starts the corresponding business process. Responding to the termination of the process call to the target computing device within the second container releases the target computing resources occupied by that container. This ensures that when it is subsequently confirmed that the computing device scheduled by other containers is the aforementioned target computing device, the target computing device does not have any target service packages loaded. Thus, simply installing the target service packages of other containers onto the target computing device allows the corresponding containers to be successfully scheduled and started. Therefore, through the container configuration method of this embodiment, when different business teams cross-use the same computing device, the container cloud can automatically switch the service packages (i.e., file systems) on the computing device, eliminating the need for cumbersome manual switching operations. This simplifies the cross-use of computing devices and improves the utilization efficiency of computing resources in the container cloud. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] in:

[0021] Figure 1 This is a flowchart illustrating an embodiment of the container configuration method provided in this application;

[0022] Figure 2 This is a schematic diagram of the overall implementation process of the container configuration method provided in this application;

[0023] Figure 3 This is a flowchart illustrating the service package loading method provided in this application;

[0024] Figure 4 yes Figure 1 The diagram shows the specific flow of step S12 in the container configuration method shown.

[0025] Figure 5 This is a flowchart illustrating another embodiment of the container configuration method provided in this application;

[0026] Figure 6 This is a flowchart illustrating yet another embodiment of the container configuration method provided in this application;

[0027] Figure 7 This is a flowchart illustrating the service package upgrade method provided in this application;

[0028] Figure 8 This is a schematic diagram of the structure of an embodiment of the container cloud provided in this application;

[0029] Figure 9 This is a schematic diagram of the structure of an embodiment of the computing node provided in this application;

[0030] Figure 10 This is a schematic diagram of the structure of an embodiment of the computing device provided in this application;

[0031] Figure 11 This is a schematic diagram of the structure of an embodiment of the computer storage medium provided in this application. Detailed Implementation

[0032] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0033] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] Kubernetes is currently the most widely used container orchestration system. Containerized applications are increasingly complex and diverse. Some application containers require the use of devices such as GPUs, FPGAs (Field Programmable Gate Arrays), and network interface cards (NICs). Kubernetes provides a device resource management mechanism to manage these resources. The registration and allocation of device resources are handled through interaction between the kubelet Device Manager module and device plugins. This interaction retrieves the device list for compute nodes and requests device resources, which are then synchronized to the Kubernetes API Server. When an application using a device is deployed, the scheduling server module allocates it to the relevant compute node. The API Server is a core module of Kubernetes, responsible for the statistics and recording of device resources. The scheduling server module, also part of Kubernetes, is primarily responsible for Pod scheduling.

[0035] In Kubernetes, a Pod is the basic unit of scheduling. A Pod can contain one or more containers that share the Pod's resources (such as network namespaces and storage volumes). These containers can be applications that require computing resources such as GPUs (e.g., deep learning training or inference tasks). Each of these containers is bound to a GPU or other computing device.

[0036] The process of binding a container to a GPU device can include:

[0037] The client submits the pod configuration to the scheduling server;

[0038] The scheduling server responds to the pod configuration submitted by the client by querying the computing resources (e.g., GPU resources) of the compute nodes to obtain the current status of the node resources;

[0039] The scheduling server executes a scheduling algorithm based on the current state of node resources to determine the target compute node for the pod to be scheduled.

[0040] Bind the pod to be scheduled to the target compute node to notify the target compute node to create the pod;

[0041] The target compute node responds to the pod deployment command by initializing the compute device (e.g., GPU device) context and granting the pod access permissions to the compute device file in order to create the pod container and mount the compute device.

[0042] It is understood that the aforementioned computing devices may be GPU devices and / or FPGA devices, etc.

[0043] Currently, computing devices on container-centric cloud computing platforms or services built on Kubernetes (hereinafter referred to as container cloud for ease of description) are uniformly managed and allocated by the container cloud. The container cloud is then provided to different business teams for use, and these different business teams have their own customized needs when using computing devices. Based on the above usage scenario of computing devices, the following problems exist:

[0044] Each business team typically customizes its own file system based on its business when using computing devices. Each time the computing device is used, it needs to load this customized file system. As a result, when different business teams share the same computing device, they need to switch the file system on the computing device. However, this switching operation is very cumbersome. It can only be done by manually executing the relevant commands on the physical machine where the graphics card of the computing device is located, and the physical machine needs to be restarted.

[0045] This could lead to situations where computing devices are allocated to only one business team, preventing them from being used across multiple teams. Even if a team doesn't use the card, it cannot be used by other business teams, resulting in a waste of computing resources.

[0046] Based on this, this application proposes a container configuration method, which includes:

[0047] S11: In response to the deployment command of the first container, the compute node obtains the target service package of the first container.

[0048] In the container configuration method of this application, when the computing node receives the deployment instruction of the first container, it can obtain the target service package of the first container so that the target service package of the first container can be automatically loaded into the target computing device, thereby enabling the target computing device to install the target service package of the first container and run the first container using the environment after installation.

[0049] The target business package of the first container can be submitted by the business team through the client configuration of the first container. When the scheduling server determines that the binding object of the first container is a computing node, the scheduling server can send the deployment instructions of the first container to the computing node. In addition, it can also send the target business package of the first container to the computing node, so that the computing node can automatically load the target business package of the first container onto the computing device mounted on the first container based on the deployment instructions of the first container. This allows the computing device mounted on the first container to automatically install the target business package of the first container and run the first container using the installed environment.

[0050] In one example, the computing device described above is a GPU device, so the target computing device can be a target GPU device, and the target service package is the GPU service package of the first container. In another example, the computing device described above is an FPGA device, so the target computing device can be a target FPGA device, and the target service package is the FPGA service package of the first container. Additionally, in some scenarios, the computing node and the computing device can be the same physical device. In this case, the computing device (e.g., a GPU physical card) is directly plugged into the motherboard of the host server running the container. In some scenarios, the computing node and the computing device can also be separate devices. In this scenario, the computing device resides on a separate server and is provided to the computing node (computing node) via a network. This can be referred to as computing device decoupling or remote computing device.

[0051] In one implementation, such as Figure 2 and Figure 3 As shown, the Device-side (i.e., the target computing device) startup script starts a customer-defined Client process; similarly, the Host-side (i.e., the computing node) startup script starts a customer-defined Daemon process to receive messages from the Device-side, allowing the computing node to know whether the target computing device is running. The Host-side Daemon process is used to load the service package. The Device-side Client process is responsible for installing and starting the service package; this process needs to be packaged into the Device-side file system.

[0052] In one example, a compute node can pull the container image of a first container and run the daemon process defined in the container image. The target compute device of the first container can also run the client process defined in the container image. The client process running on the target compute device can connect to the client daemon process on the compute node via HDC (High-speed Data Communication) and notify the compute node's daemon process that the target compute device has started. Upon receiving the message that the target compute device has started, the compute node's daemon process can obtain the target service package from the first container and then load the target service package into the target compute device.

[0053] Specifically, the host obtains the target service package as follows: the host obtains the service address from the container deployment command; the host extracts the corresponding image file based on the service address; the host parses the image file to obtain the target service package.

[0054] S12: Load the target service package of the first container into the target computing device, wherein the first container can access the target computing device so that the target computing device can install the target service package of the first container and start the service process of the first container.

[0055] After a node obtains the target service package of the first container, it can automatically load the target service package of the first container onto the target computing device, thereby enabling the target computing device to install the target service package of the first container. After the target computing device installs the target service package of the first container (i.e., the target computing device environment configuration is complete), the first container can be successfully scheduled and started.

[0056] In one embodiment, after the Daemon process on the Host side receives a message that the target computing device has been started, it copies the corresponding service package to the target computing device through the HDC file transfer function, and notifies the Client process of the target computing device to install and start the service package.

[0057] After receiving the service package installation message, the Client process of the target computing device performs the service package installation operation.

[0058] Specifically, for one particular implementation method of loading the target service package by the Client process of the target computing device, please refer to 4. Figure 4 yes Figure 1 The diagram shows the detailed process of step S12 in the container configuration method.

[0059] like Figure 4 As shown, the specific steps are as follows:

[0060] Step S121: The target computing device decompresses the target service package.

[0061] In this embodiment of the application, the Client process of the target computing device decodes the target service package .tar.gz and parses out the .so file (shared object file) and the app executable file (application executable file).

[0062] Step S122: The target computing device executes the installation script, copying the shared object files and application executable files of the target service package to the specified directory.

[0063] In this embodiment, the Client process of the target computing device executes an installation script to copy the .so file and app executable file of the target service package to a specified directory.

[0064] Step S123: After the target computing device is installed, execute the startup script to start the business process.

[0065] In this embodiment, after the file copy is complete, the Client process of the target computing device executes the uninstallation script, stops the service process, and deletes the installation file of the target service package. Finally, the Client process of the target computing device executes the service startup script to start the service process.

[0066] In this application, the computing node obtains the target service package of the first container; the computing node loads the target service package into the target computing device; the target computing device installs the target service package and starts the corresponding service process. This container configuration method considers the customized needs of different business users when using computing devices, improving the flexibility of computing device use and also increasing device utilization from another perspective.

[0067] Furthermore, to further improve the reliability of the above container configuration method, such as Figure 5 As shown, this application proposes another embodiment of a container configuration method. This embodiment of the container configuration method includes the following steps:

[0068] S21: In response to the process in the second container ending its call to the target computing device, destroy the runtime environment of the second container and release the computing resources it occupies.

[0069] In this embodiment, after a container finishes calling the target computing device, it triggers a cleanup action on the target service package on the target computing device. This causes the target computing device to unload the target service package, destroying the container's runtime environment and releasing the target computing resources occupied by the container. This ensures that when other containers are subsequently confirmed to be using the same target computing device, no target service package from any container is loaded on that device. Therefore, simply installing the target service package of other containers onto the target computing device allows the corresponding containers to be successfully scheduled and started. Thus, through this container configuration method, when different business teams share the same computing device, the container cloud can automatically switch the service packages (i.e., file systems) on the computing device, eliminating the need for cumbersome manual switching operations. This simplifies the cross-use of computing devices and improves the utilization efficiency of computing resources in the container cloud.

[0070] In response to the termination of the process call to the target computing device within the second container, the node or scheduling server can issue an uninstallation command to the target computing device, and in response to the uninstallation command, uninstall the target service package on the target computing device.

[0071] In one implementation, in response to the process in the second container ending its call to the target computing device, the computing node will unload the target service package on the target computing device. If the unloading fails, the computing node will repeatedly try to unload the target service package on the target computing device until the target service package is successfully unloaded.

[0072] In another implementation, in response to the termination of the call to the target computing device by the process within the second container, the compute node unloads the target service package from the target computing device. If the unloading fails, the compute node can respond to the deployment command of the first container and unload the target service package from the target computing device again until the target service package is successfully unloaded.

[0073] Of course, in another implementation, when the process within the second container finishes calling the target computing device, the compute node may not unload the target service package from the target computing device. Only upon receiving the deployment instruction from the first container will the compute node unload the target service package of the second container from the target computing device. This unloading process releases the target computing resources occupied by the second container, allowing the compute node to load and install the target service package of the first container to complete the deployment of the first container.

[0074] The aforementioned unloading of the target service package from the target computing device by the computing node can be achieved as follows: the computing node sends a service package uninstallation command to the client process of the target computing device through a daemon process. Then, in response to the service package uninstallation command, the client process on the computing device calls the original service package uninstallation script to perform the service package uninstallation operation. The service package uninstallation operation can include the following two parts to prevent conflicts: 1. Stopping the original service process; 2. Deleting the original service package installation files.

[0075] S22: In response to the deployment command of the first container, the compute node obtains the target service package of the first container.

[0076] For details, please refer to step S11, which will not be elaborated here.

[0077] S23: Load the target service package of the first container into the target computing device, wherein the first container can access the target computing device so that the target computing device can install the target service package of the first container and start the service process of the first container.

[0078] For details, please refer to step S12, which will not be elaborated here.

[0079] In this application, in response to the process within the second container ending its call to the target computing device, the runtime environment of the second container is destroyed, and the computing resources of the target computing device it occupies are released. Then, the computing node obtains the target service package of the first container; the computing node loads the target service package onto the target computing device; the target computing device installs the target service package and starts the corresponding business process. In response to the process within the second container ending its call to the target computing device, the target computing resources occupied by that container are released. This ensures that when it is subsequently confirmed that the computing device scheduled by other containers is the aforementioned target computing device, the target computing device does not have any target service packages of any container loaded. Thus, simply installing the target service packages of other containers onto the target computing device allows the corresponding containers to be successfully scheduled and started. Therefore, through the container configuration method of this embodiment, when different business teams cross-use the same computing device, the container cloud can automatically switch the service packages (i.e., file systems) on the computing device, eliminating the need for cumbersome manual switching operations. This simplifies the cross-use of computing devices and improves the utilization efficiency of computing resources in the container cloud.

[0080] Furthermore, in this technology, all GPUs on a physical machine can only load one file system. This means that if a GPU on a node is used by one team, it cannot be used by other teams that need to load custom file systems, which also leads to a waste of GPU resources.

[0081] like Figure 2As shown, in the container configuration method of this application, different computing devices on the same computing node are independent of each other. Each computing device interacts with the same computing node through the process interaction flow between the node and the device to obtain the target service package that each computing device needs to load and install. In this way, multiple computing devices (such as GPU graphics cards) on a physical machine can load their respective service packages (i.e., file systems).

[0082] Among them, the process interaction flow between nodes and devices can refer to the interaction flow established between the daemon process on the computing node and the client process on the computing device.

[0083] For the service package loading process described in this application embodiment, please refer to [link / reference needed]. Figure 3 , Figure 3 This is a flowchart illustrating the service package loading method provided in this application. Figure 3 This demonstrates the detailed implementation process of loading different service packages onto the corresponding computing devices. Since the host side loads a public file system, and according to... Figure 2 and Figure 3 The general container configuration method shown does not require switching the file system on the host when different computing devices load service packages, or when different computing devices load different service packages, and can automatically complete the service package loading process.

[0084] It should be noted that, Figure 2 The compute nodes shown load a common file system, which is a business file system with a unified format that can be accessed by all devices (compute equipment).

[0085] Furthermore, depending on the actual scheduling situation, at least two containers can be bound to the same computing device. For example, at least two containers belonging to the same pod can be bound to the same computing device. In this case, at least two logical devices can be generated for the computing device, and then the at least two containers are bound to the at least two logical devices one-to-one. Combined with the container configuration method of this application, a process interaction flow between nodes and devices can be established on a logical device basis. Then, the target service package of the corresponding container can be loaded and installed on each logical device using the container configuration method of this application. In this case, the target computing device in steps S11, S12, S21, S22, and S23 is the target logical device.

[0086] Additionally, for the computing device side, the steps for implementing the container configuration method include:

[0087] In response to the termination of the process call to the target computing device within the second container, the target computing device performs an unloading operation of the target service package of the second container;

[0088] In response to the deployment command of the first container, the target computing device obtains the target service package of the first container through the computing node;

[0089] The target computing device installs the target service package of the first container and starts the service process of the first container.

[0090] Furthermore, the container configuration method of this application can achieve, in addition to... Figure 3 In addition to the container configuration method shown, this document also demonstrates how to upgrade service packages for computing devices. Please refer to the following for details. Figure 6 and Figure 7 , Figure 6 This is a flowchart illustrating another embodiment of the container configuration method provided in this application. Figure 7 This is a flowchart illustrating the service package upgrade method provided in this application.

[0091] like Figure 6 As shown, Figure 6 The container configuration method shown illustrates the process of upgrading a service package on the Device side. The specific steps are as follows:

[0092] Step S31: The computing node receives the service package upgrade request through the daemon process and loads the upgrade service package onto the target computing device.

[0093] In the embodiments of this application, such as Figure 7 As shown, when a client needs to upgrade its service package, it first notifies the client daemon process on the host side to perform the service package upgrade. Upon receiving the client's upgrade request, the host daemon process first loads the service package onto the device via HDC file transfer, and then sends a message to the client process on the device side, notifying it to perform the service package upgrade.

[0094] Step S32: The target computing device stops the current business process and installs the upgrade service package.

[0095] In this embodiment, after receiving a customer upgrade message, the Client process on the Device side calls the original service package uninstallation script to perform a service package uninstallation operation. The service package uninstallation operation needs to include the following two parts to prevent conflicts: 1. Stopping the original service process; 2. Deleting the original service package installation files.

[0096] It should be noted that the client process on the device side can only perform the installation of the new service package after the original service package has been uninstalled.

[0097] Specifically, the client process on the device side first decrypts and verifies the signature of the service package, then decompresses the service package, executes the installation script to install it, and after successful installation, executes the startup script to start the service process. In other embodiments, users can implement the decryption / signature verification of the service package themselves or through other modules as needed.

[0098] This part is related to Figure 3 The process of loading the business package in the container configuration method shown is basically the same, so it will not be described again here.

[0099] Step S33: After the upgrade service package is installed, the target computing device starts a new service process.

[0100] In this embodiment of the application, after the service package is installed on the Device side, the Client process on the Device side notifies the Daemon process on the Host side that the service package upgrade operation has been completed.

[0101] The container configuration method in this application takes into account the customized needs of business users when using computing devices, improves the flexibility of computing device use, and can also improve the utilization of computing devices from another perspective. By providing a mechanism for dynamically loading the business packages of computing device users, it is not necessary to manually reload the file system on the computing device on the physical machine, which simplifies the cross-use of computing devices among different business teams and improves their utilization.

[0102] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0103] To achieve the aforementioned container cloud, this application also proposes a container cloud approach, for details please refer to [link / reference needed]. Figure 8 , Figure 8 This is a schematic diagram of the structure of an embodiment of the container cloud provided in this application.

[0104] The container cloud 500 in this embodiment includes: a computing node 51 and a computing device 52.

[0105] The computing node 51 is used to obtain the target service package of the first container in response to the deployment instruction of the first container.

[0106] The computing node 51 is used to load the target service package of the first container into the target computing device 52, wherein the first container can access the target computing device 52 to allow the target computing device 52 to install the target service package of the first container and start the service process of the first container.

[0107] To implement the above container configuration method, this application also proposes a compute node, which can be found in the following details. Figure 9 , Figure 9 This is a schematic diagram of the structure of an embodiment of the computing node provided in this application.

[0108] The computing node 400 in this embodiment includes a processor 41, a memory 42, an input / output device 43, and a bus 44.

[0109] The processor 41, memory 42, and input / output device 43 are respectively connected to the bus 44. The memory 42 stores program data, and the processor 41 is used to execute the program data to implement the container configuration method described in the above embodiments.

[0110] In this embodiment, processor 41 can also be referred to as a CPU (Central Processing Unit). Processor 41 may be an integrated circuit chip with signal processing capabilities. Processor 41 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor, or processor 41 can be any conventional processor.

[0111] To implement the above container configuration method, this application also proposes a computing device, which can be found in the following details. Figure 10 , Figure 10 This is a schematic diagram of the structure of an embodiment of the computing device provided in this application.

[0112] The computing device 600 in this embodiment includes a processor 61, a memory 62, an input / output device 63, and a bus 64.

[0113] The processor 61, memory 62, and input / output device 63 are respectively connected to the bus 64. The memory 62 stores program data, and the processor 61 is used to execute the program data to implement the container configuration method described in the above embodiments.

[0114] This application also provides a computer storage medium; please refer to the following: Figure 11 , Figure 11This is a schematic diagram of a computer storage medium according to an embodiment of the present application. The computer storage medium 700 stores a computer program 71, which, when executed by a processor, is used to implement the container configuration method of the above embodiment.

[0115] When the embodiments of this application are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0116] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A container configuration method, characterized in that, The container configuration method is applied to a container cloud, which includes compute nodes and compute devices; the container configuration method includes: In response to the termination of the process call to the target computing device within the second container, the computing node destroys the runtime environment of the second container and releases the computing resources of the target computing device it occupies. In response to the deployment command of the first container, the compute node obtains the target service package of the first container; The computing node loads the target service package of the first container into the target computing device, wherein the first container can access the target computing device to allow the target computing device to install the target service package of the first container and start the service process of the first container.

2. The container configuration method according to claim 1, characterized in that, In response to the deployment command of the first container, the compute node obtains the target service package of the first container, including: The computing node starts a daemon process; The computing node receives a message that the target computing device has been started through the daemon process. The message that the target computing device has been started is sent by the target computing device through the client process.

3. The container configuration method according to claim 1, characterized in that, The target computing device installs the target service package of the first container, including: The target computing device decompresses the target service package; The target computing device executes an installation script to copy the shared object file and application executable file of the target service package to a specified directory; After installation, the target computing device executes a startup script to start the business process.

4. The container configuration method according to claim 1, characterized in that, The computing node obtains the target service package of the first container, including: The computing node obtains the service address from the deployment instruction; The computing node extracts the corresponding image file based on the service address; The computing node parses the image file to obtain the target service package.

5. The container configuration method according to claim 1, characterized in that, The container configuration method further includes: The computing node receives the service package upgrade request through a daemon process, loads the upgrade service package onto the target computing device, so that the target computing device stops the current service process, installs the upgrade service package, and starts a new service process.

6. The container configuration method according to claim 5, characterized in that, The target computing device stops its current service process, and then includes: Delete the service package installation file of the current service process.

7. A container configuration method, characterized in that, The container configuration method is applied to a container cloud, which includes compute nodes and compute devices; the container configuration method includes: In response to the termination of the process call to the target computing device within the second container, the target computing device performs an unloading operation of the target service package of the second container; In response to the deployment command of the first container, the target computing device obtains the target service package of the first container through the computing node; The target computing device installs the target service package of the first container and starts the service process of the first container.

8. A computing node, characterized in that, The computing node includes a memory and a processor coupled to the memory; The memory is used to store program data, and the processor is used to execute the program data to implement the container configuration method as described in any one of claims 1 to 6.

9. A computing device, characterized in that, The computing device includes a memory and a processor coupled to the memory; The memory is used to store program data, and the processor is used to execute the program data to implement the container configuration method as described in claim 7.

10. A computer storage medium, characterized in that, The computer storage medium is used to store program data, which, when executed by the computer, is used to implement the container configuration method as described in any one of claims 1 to 7.

Images