Methods, apparatus, equipment and storage media for managing container status

Abstract

This invention discloses a method, apparatus, device, and storage medium for managing container status. The method includes: upon receiving a shutdown request for a target container group, receiving a shutdown configuration file containing container group association data for the target container group; querying the server node where the target container group resides based on the shutdown configuration file, creating a temporary execution task on the server node, and issuing a container commit command to the temporary execution task through the container engine's application programming interface; saving all content within the target container group as a container image based on the container commit command; and shutting down the target container group upon completion of the container commit command. This achieves the technical effects of ensuring no loss of content within the container group, improving the flexibility of container usage, and avoiding data loss due to single points of failure.

Description

Technical Field

[0001] This invention relates to the field of containerized workload management technology, and in particular to a method, apparatus, device and storage medium for managing container status. Background Technology

[0002] With the widespread adoption of containerization technology, container cluster management systems have become the core foundation for deploying cloud-native applications. Container groups, as the smallest deployment unit in this system, are widely used in various business scenarios. Currently, mainstream container cluster management systems only support the permanent storage of data on mounted disks. Users can perform various operations within container groups, such as software installation and system configuration modification, to meet diverse business needs.

[0003] Existing container cluster management systems have significant functional limitations, only enabling persistent storage of data on mounted disks and failing to effectively retain content on non-mounted disks within the container group. When users perform operations such as software installation and configuration parameter modification within the container group, the content on these non-mounted disks is completely lost upon restarting or shutting down the container group. This forces users to repeat the same configuration operations, significantly impacting usability and business efficiency. Furthermore, there are currently no effective solutions available for this scenario. These shortcomings have become a key issue restricting the flexible use of container groups, causing considerable inconvenience to users who rely on container groups for their business operations. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and storage medium for managing container states, so as to achieve persistent storage of system states when container groups are shut down.

[0005] According to one aspect of the present invention, a method for managing the state of a container is provided, the method comprising: Upon receiving a shutdown request for the target container group, a shutdown configuration file containing container group association data of the target container group is received; Based on the shutdown configuration file, query the server node where the target container group is located, create a temporary execution task on the server node, and issue a container commit command to the temporary execution task through the application programming interface of the container engine. Based on the container commit command, all contents within the target container group are saved as a container image. After the container commit command is completed, the target container group is shut down.

[0006] According to another aspect of the present invention, a container status management device is provided, the device comprising: The request receiving module is used to receive a shutdown configuration file containing container group association data of the target container group when a shutdown request for the target container group is received. The command delivery module is used to query the server node where the target container group is located based on the shutdown configuration file, create a temporary execution task on the server node, and issue a container submission command to the temporary execution task through the application programming interface of the container engine. The image storage module is used to save all contents within the target container group as a container image based on the container commit command, and to shut down the target container group after the container commit command has been executed.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and memory that is communicatively connected to at least one processor; The memory stores a computer program that can be executed by at least one processor, which enables the at least one processor to perform the container state management method of any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, which stores computer instructions for causing a processor to execute a container state management method according to any embodiment of the present invention.

[0009] The technical solution of this invention, upon receiving a shutdown request for a target container group, receives a shutdown configuration file containing container group association data of the target container group; based on the shutdown configuration file, queries the server node where the target container group is located, creates a temporary execution task on the server node, and issues a container commit command to the temporary execution task through the application programming interface of the container engine; based on the container commit command, saves all contents within the target container group as a container image; and shuts down the target container group upon completion of the container commit command execution. This solves the technical problem of easy data loss on non-mounted disks when container groups are restarted or shut down in container cluster management systems, achieving the technical effect of ensuring that all contents such as software installation files and system configurations within the container group are not lost, improving the flexibility of container use, and avoiding data loss due to single points of failure.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating a container state management method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating an optional example of a container state management method provided in an embodiment of the present invention; Figure 3 A schematic diagram of a container status management device provided in an embodiment of the present invention; Figure 4 A schematic diagram of an electronic device for implementing a container state management method according to an embodiment of the present invention. Detailed Implementation

[0013] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0014] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented 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.

[0015] Figure 1 This is a flowchart illustrating a container state management method provided in an embodiment of the present invention. This embodiment is applicable to container state management situations. The method can be executed by a container state management device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method specifically includes the following steps: S110. Upon receiving a shutdown request for the target container group, receive a shutdown configuration file containing container group association data of the target container group.

[0016] In this context, the target container group can be understood as a specific collection of containers that requires state management; it is the smallest deployment unit in a container cluster management system. A shutdown request can be understood as an instruction that triggers the target container group to stop running. Container group association data can be understood as a set of key information used to uniquely identify the target container group. A shutdown configuration file can be understood as a specific format file that carries the container group association data.

[0017] Specifically, when the system receives a command to stop the target container group, either manually initiated by the user or automatically scheduled by the system, it will simultaneously receive a shutdown configuration file containing associated data that can uniquely identify the target container group, so as to achieve accurate location and processing of the target container group in the future.

[0018] Optionally, the container group association data includes namespace, container group name, and container name.

[0019] In this context, a namespace can be understood as a logical partition used to isolate resources in a container cluster management system. A container group name can be understood as a unique name for the target container group, used to accurately locate the container group within the namespace. A container name can be understood as a unique identifier for each container within a container group, used to distinguish different functional containers within the group.

[0020] S120. Based on the shutdown configuration file, query the server node where the target container group is located, create a temporary execution task on the server node, and issue a container commit command to the temporary execution task through the application programming interface of the container engine.

[0021] In this context, a server node can be understood as a physical or virtual server in a container cluster management system that hosts the running of container groups. A temporary execution task can be understood as a task unit temporarily created to perform a specific operation, which is automatically destroyed upon completion. The container engine can be understood as the core software that supports container creation, running, and packaging, responsible for managing the container's lifecycle. The application programming interface (API) can be understood as the control interfaces reserved by the container engine. The container commit command can be understood as the instruction used to solidify the current complete state of the container into a container image.

[0022] Specifically, the system first extracts key correlation data from the shutdown configuration file and uses this data to locate the server node where the target container group is currently running. Then, a temporary execution task is created on that server node, and a container submission command is issued to this task through the container engine's application programming interface, enabling the task to perform container packaging operations. Preferably, the temporary execution task and the target container group are deployed on the same node, which reduces network transmission latency and improves command execution efficiency.

[0023] Optionally, querying the server node where the target container group is located based on the shutdown configuration file includes: extracting the container group association data based on the shutdown configuration file, and matching the correspondence between the container group association data and the cluster nodes through the built-in query function of the container cluster management system to determine the running node of the target container group.

[0024] The container cluster management system can be understood as a core platform used to uniformly manage all container groups, server nodes and other resources within the cluster, providing functions such as resource scheduling and querying.

[0025] Specifically, firstly, container group association data, including namespace, container group name, and container name, is extracted from the shutdown configuration file that carries key identification information to uniquely identify the target container group. This data is the core search keyword for locating the container group, ensuring it is not confused with other container groups within the cluster. Then, the built-in query function of the container cluster management system is invoked. This function can quickly traverse the resource lists of all server nodes in the cluster. By accurately matching the extracted container group association data with the container group information running on each node, such as namespace isolation matching and name uniqueness matching, the server node currently running the target container group is ultimately located.

[0026] Preferably, a data verification mechanism can be added during the matching process to first verify the format integrity of the container group-related data, such as whether necessary name fields are missing. If data anomalies are found, error reports should be submitted promptly. Simultaneously, a combination of fuzzy and precise matching is supported. When precise matching fails, some key data (such as container group names) can be used to assist in troubleshooting, improving the fault tolerance and efficiency of node location. This step relies on the system's native functions and standardized data matching logic to ensure the accuracy and real-time nature of the location results, laying the foundation for subsequent operations such as creating temporary execution tasks and locally packaging container images.

[0027] S130. Based on the container commit command, save all contents in the target container group as a container image, and close the target container group after the container commit command is completed.

[0028] A container image can be understood as a static template that contains all the contents of a container (data, configuration, software, etc.).

[0029] Specifically, the temporary execution task receives and executes the container commit command, creating a data snapshot only for the container's system disk, and persistently storing the runtime data in the target container group's system disk. For mounted disks, since this type of data is inherently real-time persistent, this commit operation does not include mounted disk data. After the first step (Commit step) in the pending image generation process is completed, the system executes the shutdown operation of the target container group. For example, Commit persistently saves the runtime data in memory to the server's system disk image file. After the above Commit step is completed, without waiting for the subsequent Save image packaging step, the system can directly execute the shutdown operation of the target container group to release computing resources and ensure data integrity.

[0030] Optionally, all content within the target container group includes software installation files, system configuration data, and temporary runtime data stored on a non-mounted disk.

[0031] In this context, software installation files stored on non-mounted disks can be understood as files related to various software installed by the user within the container group that are not stored via a mounted disk. System configuration data can be understood as system parameters, runtime configurations, and other data modified by the user within the container group. Temporary runtime data can be understood as temporary data generated during the operation of the container group that is not persistently stored via a mounted disk.

[0032] Optionally, if the container submission command is completed, the target container group is shut down, including: determining whether the container submission command is completed based on the execution status code fed back by the container engine in real time; and after confirming that the container image is successfully generated, triggering the shutdown process of the target container group to shut down the target container group.

[0033] The execution status code can be understood as a status indicator returned by the container engine after executing a command, used to determine whether the command was executed successfully.

[0034] Specifically, the core criterion for determining whether a container submission command has been completed is the execution status code provided by the container engine in real time. Different status codes correspond to different situations: command execution successful, failed, or in progress. Only when the status code indicates that the command has been executed successfully and the container image has been successfully generated will the shutdown process of the target container group be triggered, preventing data loss within the container due to image saving failure. Preferably, if the status code indicates execution failure, the system will automatically retry the container submission command. The number of retries can be pre-configured based on experience; this embodiment does not impose specific limitations on it.

[0035] Optionally, after saving the contents of the target container group as a container image based on the container submission command, the method further includes: pushing the container image to a remote image repository for off-site storage.

[0036] In this context, a remote image repository can be understood as an image storage service deployed on a remote server, used to store container images in a different location.

[0037] Specifically, after successfully saving the contents of the target container group as a container image using the container commit command, the container image is then uploaded to a remote image repository. When pushing the container image to the remote image repository, a naming convention that includes the container group name and the operation timestamp is used, supporting differentiated management of image versions and tracking of historical versions.

[0038] Preferably, encrypted transmission can be used during the image push process to prevent image data from being stolen or tampered with.

[0039] In this embodiment of the invention, by using off-site storage, even if the server node carrying the original container group experiences a crash or failure, the container image can be safely preserved, providing a guarantee for the subsequent recovery of the container group.

[0040] Optionally, after shutting down the target container group, the method further includes: if it is necessary to restart the target container group, restoring all content of the target container group before it was shut down by specifying the container image.

[0041] Specifically, when it is necessary to restart a closed target container group, by specifying a previously saved container image in the startup configuration, the system will create a new container group based on that image. This ensures that the content and configuration of the new container group are completely consistent with the original container group before it was shut down, achieving seamless recovery of the container group's state. Preferably, multiple historical image versions can be selected to meet users' needs for restoring to a state at different points in time.

[0042] The technical solution of this invention, upon receiving a shutdown request for a target container group, receives a shutdown configuration file containing container group association data of the target container group; based on the shutdown configuration file, queries the server node where the target container group is located, creates a temporary execution task on the server node, and issues a container commit command to the temporary execution task through the application programming interface of the container engine; based on the container commit command, saves all contents within the target container group as a container image; and shuts down the target container group upon completion of the container commit command execution. This solves the technical problem of easy data loss on non-mounted disks when container groups are restarted or shut down in container cluster management systems, achieving the technical effect of ensuring that all contents such as software installation files and system configurations within the container group are not lost, improving the flexibility of container use, and avoiding data loss due to single points of failure.

[0043] Figure 2 This is a flowchart illustrating an optional example of a container state management method provided by an embodiment of the present invention. For example... Figure 2 As shown, the method specifically includes the following steps: Step 1. The container cluster management system (Kubernetes) can create a controller to handle the task of shutting down container groups (PODs).

[0044] Specifically, the controller is a core, resident control component in the container cluster management system, dedicated to coordinating and scheduling container group shutdown. By pre-creating this controller, the container group shutdown process can be automatically triggered and managed without manual intervention. This provides a unified command entry point for subsequent operations such as container group state saving and shutdown execution, ensuring a standardized and orderly shutdown process.

[0045] Step 2. After the controller receives the YAML configuration file for shutting down the container group (POD), the YAML configuration file will specify the specific information of the container group (POD), including the namespace, container group name (podname), and container name (containername).

[0046] Specifically, the YAML (Yeast Object Modeling) configuration file is the carrier of shutdown commands and target container group identification information. Its format is highly readable and clearly structured, making it easy for the controller to parse. It includes a namespace (used for resource isolation, distinguishing container groups in different scenarios), a container group name (uniquely identifying a specific container group), and a container name (distinguishing different functional containers within the container group). The combination of these three elements allows for precise location of the target container group, preventing accidental operations in multi-container cluster environments.

[0047] Step 3. By querying the container cluster management system (k8s) using the specific information mentioned above, you can find out the server node where the container group (POD) is located.

[0048] Specifically, the container cluster management system possesses global cluster resource awareness capabilities. After the controller extracts the target container group identification information from the YAML (Yet-In-the-Language) configuration file, it uses the system's built-in query function to traverse the resource lists of all server nodes within the cluster, matching the correspondence between the target container group and the node, and ultimately determining the physical or virtual server node where the target container group is currently running. The core purpose of this step is to locate the runtime environment of the container group, laying the location foundation for subsequent state saving operations performed on the same node.

[0049] Step 4. On the server node (node) where the container group (POD) is located, create an execution task (job) corresponding to the controller.

[0050] Specifically, an execution task is a one-time execution unit temporarily created by the controller on the target node, responsible only for performing specific operations related to saving the container group's state. Deploying execution tasks on the node where the target container group resides reduces latency caused by cross-node network transmission, ensuring more efficient and stable subsequent interaction with the container engine (Docker), while also avoiding operation failures due to cross-node communication failures.

[0051] Step 5. The container (job pod) corresponding to the job execution task on the server node (node) controls the container engine (docker) through the application programming interface (API) of the container engine (docker), and then sends the container commit command (docker commit) to the container engine (docker).

[0052] Specifically, the execution task itself does not have container packaging capabilities; it needs to implement programmatic calls to the container engine through the application programming interface (API) reserved by the container engine. The container commit command is a core instruction supported by the container engine. Its function is to solidify the current complete running state of the container into a static image, which is a key operation to achieve persistence of the contents of the container group's non-mounted disk, providing technical support for subsequent content preservation.

[0053] Step 6. The container commit command (docker commit) will save all the contents of the container (the target container within the container group) to the container image (docker image). You can also execute the image push command (docker push) to push the container image (docker image) to a remote image repository.

[0054] Specifically, after the container commit command is executed, a complete snapshot of all contents within the target container, including software installation files, system configuration data, and temporary runtime data stored on non-mounted disks, is taken and packaged to generate a container image, i.e., a static template file, thus solidifying the container's running state. The image push command (docker push) is an optional off-site backup step that uploads the container image to a remote image repository. This avoids image loss due to target node downtime or failure, further ensuring the security of container group state data.

[0055] Step 7. After the container commit command (docker commit) is executed, the container group (POD) can be shut down.

[0056] Specifically, the controller monitors the execution status of container submission commands in real time. Only after confirming successful container image generation through the execution results returned by the container engine does it trigger the container group shutdown process. This ensures that all content within the container group is fully preserved, preventing data loss due to premature shutdown of the container group before image generation is complete, and guaranteeing consistency between the shutdown and state preservation processes.

[0057] Step 8. When starting the container group (POD), specify the container image (docker image) generated by the container commit command (docker commit) above. At this time, the entire contents of the container group (POD) will be restored.

[0058] Specifically, the container image contains the complete state and all content of the container group before it was shut down. Specifying this image at startup allows the container cluster management system to create new container instances based on the image, automatically restoring all software, configurations, data, and other content stored in the image, ensuring that the newly started container group is completely consistent with its state before shutdown. This achieves seamless recovery of the container group state and completely solves the problem of losing content on non-mounted disks when the container group is shut down or restarted.

[0059] Preferably, the container cluster management system creates new container instances based on the image and triggers a scheduling policy. For example, the system will first attempt to schedule the new container instance to start on the source server where the image was last saved, in order to utilize the locally cached image and improve startup speed. If, after resource assessment, the source server's resources are insufficient (such as limited CPU, memory, or network resources) and cannot meet the scheduling requirements, the system will automatically trigger the cross-node image copy mechanism to synchronize the image file from the source server to other target servers with available resources. After the image copy is completed, the new container instance will be started on the target server, thereby ensuring business continuity and deployment flexibility.

[0060] The technical solution of this invention addresses the problem of data loss on non-mounted disks when container groups (PODs) are restarted or shut down in a container cluster management system (Kubernetes). It proposes a solution that involves the controller receiving a shutdown configuration file containing specific information about the target container group, locating the node where the container group is located and creating an execution task, using a container submission command to save all container content as an image (which can be pushed to a remote repository), and specifying the content to be restored from this image at startup. This solution solves the technical problem of data loss on non-mounted disks when container groups are restarted or shut down in a container cluster management system, achieving the technical effect of ensuring that all content within the container group, such as software installation files and system configurations, is not lost, improving the flexibility of container usage, and avoiding data loss due to single points of failure.

[0061] Figure 3 This is a schematic diagram of a container status management device provided in an embodiment of the present invention. Figure 3As shown, the device includes: a request receiving module 310, a command issuing module 320, and a mirror storage module 330.

[0062] The request receiving module 310 is used to receive a shutdown configuration file containing container group association data of the target container group when a shutdown request for the target container group is received; the command issuing module 320 is used to query the server node where the target container group is located based on the shutdown configuration file, create a temporary execution task on the server node, and issue a container commit command to the temporary execution task through the application programming interface of the container engine; the image storage module 330 is used to save all contents in the target container group as a container image based on the container commit command, and shut down the target container group when the container commit command is executed.

[0063] The technical solution of this invention, upon receiving a shutdown request for a target container group, receives a shutdown configuration file containing container group association data of the target container group; based on the shutdown configuration file, queries the server node where the target container group is located, creates a temporary execution task on the server node, and issues a container commit command to the temporary execution task through the application programming interface of the container engine; based on the container commit command, saves all contents within the target container group as a container image; and shuts down the target container group upon completion of the container commit command execution. This solves the technical problem of easy data loss on non-mounted disks when container groups are restarted or shut down in container cluster management systems, achieving the technical effect of ensuring that all contents such as software installation files and system configurations within the container group are not lost, improving the flexibility of container use, and avoiding data loss due to single points of failure.

[0064] Optionally, the device further includes: The off-site storage module is used to push the container image to a remote image repository for off-site storage after the contents of the target container group are saved as a container image based on the container submission command.

[0065] Optionally, the device further includes: The recovery module is used to restore all content of the target container group before it was shut down, by specifying the container image, in the event that the target container group needs to be restarted after it has been shut down.

[0066] Optionally, the mirror storage module is specifically used for: Based on the execution status code fed back by the container engine in real time, it is determined whether the container submission command has been completed. After confirming that the container image has been successfully generated, the shutdown process of the target container group is triggered to shut down the target container group.

[0067] Optionally, the container group association data includes namespace, container group name, and container name.

[0068] Optionally, the command issuing module is specifically used for: Based on the closed configuration file, the container group association data is extracted, and the correspondence between the container group association data and the cluster nodes is matched using the built-in query function of the container cluster management system to determine the running node of the target container group.

[0069] Optionally, all content within the target container group includes software installation files, system configuration data, and temporary runtime data stored on a non-mounted disk.

[0070] The container status management device provided in this embodiment of the invention can execute the container status management method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0071] Figure 4 This is a schematic diagram of an electronic device for implementing the container state management method of this invention. The electronic device is intended to represent various forms of digital computers, such as laptops, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0072] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0073] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0074] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the management of method container states.

[0075] In some embodiments, the management of the method container state can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the management of the method container state described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the management of the method container state by any other suitable means (e.g., by means of firmware).

[0076] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0077] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0078] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0079] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0080] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0081] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0082] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0083] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for managing the state of a container, characterized in that, include: Upon receiving a shutdown request for the target container group, a shutdown configuration file containing container group association data of the target container group is received; Based on the shutdown configuration file, query the server node where the target container group is located, create a temporary execution task on the server node, and issue a container commit command to the temporary execution task through the application programming interface of the container engine. Based on the container commit command, all contents within the target container group are saved as a container image. After the container commit command is completed, the target container group is shut down.

2. The method according to claim 1, characterized in that, After saving the contents of the target container group as a container image based on the container commit command, the method further includes: The container image is pushed to a remote image repository for off-site storage.

3. The method according to claim 1, characterized in that, Following the closure of the target container group, the following is also included: If the target container group needs to be restarted, the contents of the target container group before it was shut down can be restored by specifying the container image.

4. The method according to claim 1, characterized in that, After the container commit command has been executed, shutting down the target container group includes: Based on the execution status code fed back by the container engine in real time, it is determined whether the container submission command has been completed. After confirming that the container image has been successfully generated, the shutdown process of the target container group is triggered to shut down the target container group.

5. The method according to claim 1, characterized in that, The associated data for the container group includes the namespace, container group name, and container name.

6. The method according to claim 1, characterized in that, The step of querying the server node where the target container group is located based on the closed configuration file includes: Based on the closed configuration file, the container group association data is extracted, and the correspondence between the container group association data and the cluster nodes is matched using the built-in query function of the container cluster management system to determine the running node of the target container group.

7. The method according to claim 1, characterized in that, All contents within the target container group include software installation files, system configuration data, and temporary runtime data stored on the non-mounted disk.

8. A container status management device, characterized in that, include: The request receiving module is used to receive a shutdown configuration file containing container group association data of the target container group when a shutdown request for the target container group is received. The command delivery module is used to query the server node where the target container group is located based on the shutdown configuration file, create a temporary execution task on the server node, and issue a container submission command to the temporary execution task through the application programming interface of the container engine. The image storage module is used to save all contents within the target container group as a container image based on the container commit command, and to shut down the target container group after the container commit command has been executed.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the container state management method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method for managing the state of a container as described in any one of claims 1-7.

Images