Container management method and device based on container orchestration engine and storage medium

Abstract

This invention discloses a container management method, apparatus, and storage medium based on a container orchestration engine. The method includes: determining whether a target container has a target tag, obtaining a determination result, wherein the target tag is used to control the survival status of the target container; and managing the target container using a container orchestration engine based on the determination result. This invention solves the technical problem of poor system stability caused by unexpected container deletion in the container orchestration engine.

Description

Technical Field

[0001] This invention relates to the field of computers, and more specifically, to a container management method, apparatus, and storage medium based on a container orchestration engine. Background Technology

[0002] With the maturity of Kubernetes (Kubernetes) technology and the increasing cost of enterprise machines, more and more enterprises are using Kubernetes as a resource management platform for container management to improve machine resource utilization and application hybrid deployment scheduling efficiency, and to achieve resource isolation between applications after hybrid deployment.

[0003] In related technologies, in order to ensure the stability of its components and resource utilization, Kubernetes may trigger unexpected deletion operations of containers or deployable computing units (Pods) under certain circumstances. Since user applications run in Pods as containers, the stability and capacity of the business will be affected to a certain extent when containers or Pods are unexpectedly deleted.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This invention provides a container management method, apparatus, and storage medium based on a container orchestration engine, to at least solve the technical problem of poor system stability caused by unexpected container deletion in the container orchestration engine.

[0006] According to one aspect of the present invention, a container management method based on a container orchestration engine is provided, comprising: determining whether a target container has a target tag and obtaining a determination result, wherein the target tag is used to control the existence status of the target container; and managing the target container using a container orchestration engine based on the determination result.

[0007] Optionally, managing the target container using the container orchestration engine based on the judgment result includes: performing a first process on the target container based on the judgment result to obtain a first result, wherein the first result is used to represent the target container's tolerance for key-value attribute data; performing a second process on the target container based on the judgment result to obtain a second result, wherein the second result is used to represent the target container's inclusion verification status; and performing a third process on the target container based on the judgment result to obtain a third result, wherein the third result is used to represent the target container's eviction processing status.

[0008] Optionally, the first processing of the target container based on the judgment result includes: in response to the existence of a target label in the target container, stopping the tolerance check on the target container and retaining the target container; in response to the absence of a target label in the target container, determining whether the target container has performed multiple preset change operations based on key-value attribute data, obtaining a target determination result, and deleting the target container based on the target determination result.

[0009] Optionally, the second processing of the target container based on the judgment result includes: in response to the target container not having a target label, performing a management verification on the target container based on a preset standard, and deleting the target container based on the management verification result; in response to the target container having a target label, performing status monitoring and resource allocation on the target container.

[0010] Optionally, the third processing of the target container based on the judgment result includes: in response to the existence of a target label in the target container, controlling the container orchestration engine to stop transmitting the abnormal state information of the target container and retaining the target container.

[0011] Optionally, target key-value pairs are added during the creation of the target container, where the target key-value pairs are used to set the target label.

[0012] According to another aspect of the present invention, a container management device based on a container orchestration engine is also provided, comprising: a judgment module, configured to judge whether a target container has a target tag and obtain a judgment result, wherein the target tag is used to control the existence status of the target container; and a management module, configured to manage the target container using the container orchestration engine based on the judgment result.

[0013] Optionally, the management module is further configured to: perform a first process on the target container based on the judgment result to obtain a first result, wherein the first result is used to represent the tolerance of the target container for key-value attribute data; perform a second process on the target container based on the judgment result to obtain a second result, wherein the second result is used to represent the management verification status of the target container; and perform a third process on the target container based on the judgment result to obtain a third result, wherein the third result is used to represent the eviction processing status of the target container.

[0014] Optionally, the management module is also configured to: in response to the existence of a target label in the target container, stop the tolerance check on the target container and retain the target container; in response to the absence of a target label in the target container, determine whether the target container has performed multiple preset change operations based on key-value attribute data, obtain the target determination result, and delete the target container based on the target determination result.

[0015] Optionally, the management module is also used to: in response to the absence of a target label in the target container, perform management verification on the target container based on preset standards, and delete the target container based on the management verification result; in response to the presence of a target label in the target container, perform status monitoring and resource allocation on the target container.

[0016] Optionally, the management module is also used to: in response to the existence of a target label in the target container, control the container orchestration engine to stop transmitting abnormal state information of the target container and retain the target container.

[0017] Optionally, the container management apparatus based on the container orchestration engine further includes: a creation module for adding target key-value pairs during the creation of a target container, wherein the target key-value pairs are used to set target tags.

[0018] According to another aspect of the present invention, a non-volatile storage medium is also provided, wherein a computer program is stored in the storage medium, and the computer program is configured to execute the container management method based on the container orchestration engine described above at runtime.

[0019] According to another aspect of the present invention, a processor is also provided, the processor being used to run a program, wherein the program is configured to execute the container management method based on the container orchestration engine described above at runtime.

[0020] According to another aspect of the present invention, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the container management method based on the container orchestration engine described above.

[0021] In this embodiment of the invention, a judgment result is obtained by determining whether the target container has a target tag. The target tag is used to control the existence status of the target container. Then, the container orchestration engine manages the target container based on the judgment result, thereby avoiding the unexpected deletion of the container and achieving the technical effect of improving system stability. This solves the technical problem of poor system stability caused by the unexpected deletion of containers in the container orchestration engine. Attached Figure Description

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

[0023] Figure 1 This is a schematic diagram of the architecture of a set of container orchestration engines in related technologies;

[0024] Figure 2This is a flowchart of a container management method based on a container orchestration engine according to one embodiment of the present invention;

[0025] Figure 3 This is a structural block diagram of a container management device based on a container orchestration engine according to one embodiment of the present invention. Detailed Implementation

[0026] 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.

[0027] 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.

[0028] First, some nouns or terms that appear in the description of the embodiments of the present invention shall be interpreted as follows:

[0029] Container Orchestration Engine (Kubernetes): Kubernetes is a containerized application engine used to manage multiple hosts on a cloud platform. Kubernetes can provide the following types of functions: service discovery and load balancing, storage orchestration, automatic deployment and rollback, automatic binning calculation, self-healing, and key and configuration management. Figure 1 This is a schematic diagram of the architecture of a set of container orchestration engines in related technologies, such as Figure 1 As shown, Kubernetes includes the following components:

[0030] MasterNode: Used to make global decisions for the cluster, such as resource scheduling, and detecting and responding to cluster events;

[0031] Application Programming Interface Server (apiserver): One of the Master Node components, this component is responsible for exposing the Kubernetes application programming interface and handling incoming requests;

[0032] Scheduler: One of the MasterNode components, responsible for monitoring newly created Pods that have not been assigned a running node, and selecting a node for the Pod to run on.

[0033] Controllermanager: One of the MasterNode components, responsible for running the controller process. The controller monitors the public state of the Kubernetes cluster through the apiserver and strives to transform the current state into the desired state.

[0034] Storage system (Etcd): It is a key-value database that balances consistency and high availability, and can serve as the backend database for storing all cluster data in Kubernetes;

[0035] WorkNode: The node component runs on each node and is responsible for maintaining the running Pods and providing the Kubernetes runtime environment;

[0036] Kubelet: Runs on every node in the cluster to ensure that containers are running in Pods;

[0037] Network proxy (Kube-proxy): A network proxy that runs on each node in the cluster, implementing part of the Kubernetes service concept;

[0038] Pod: The smallest deployable unit of computing created and managed in Kubernetes; it is a collection of containers.

[0039] To ensure the stability of its components and resource utilization, Kubernetes will trigger unexpected container or pod deletion operations in the following scenarios: when a worker node has taints, but the pods on it do not have tolerance for those taints; when the kubelet starts managing an existing pod, and the pod cannot meet the management requirements; when worker node hardware resources (CPU, memory, file handles, temporary space, etc.) are scarce. Since user applications run in containers within pods, unexpected deletion of containers or pods will have a certain impact on the stability and capacity of the business.

[0040] According to an embodiment of the present invention, a container management method based on a container orchestration engine is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0041] This method embodiment can be executed in an electronic device or similar computing device that includes memory and a processor. Taking operation on a computer terminal as an example, the computer terminal may include one or more processors (processors may include, but are not limited to, central processing units (CPUs), graphics processing units (GPUs), digital signal processing (DSP) chips, microcontroller units (MCUs), field programmable gate arrays (FPGAs), neural network processors (NPUs), tensor processing units (TPUs), artificial intelligence (AI) type processors, etc.) and memory for storing data. Optionally, the computer terminal may also include transmission devices for communication functions. Those skilled in the art will understand that the above structural description is merely illustrative and does not limit the structure of the computer terminal. For example, the computer terminal may also include more or fewer components than described above, or have a different configuration than described above.

[0042] The memory can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the container management method based on the container orchestration engine in this embodiment of the invention. The processor executes various functional applications and data processing by running the computer program stored in the memory, thereby implementing the aforementioned container management method based on the container orchestration engine. The memory may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0043] The transmission device is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the mobile terminal's communication provider. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0044] The display device can be, for example, a touchscreen liquid crystal display (LCD) and a touch display (also referred to as a "touchscreen" or "touch display"). This LCD allows the user to interact with the user interface of the mobile terminal. In some embodiments, the mobile terminal has a graphical user interface (GUI), which allows the user to interact with the GUI by touching and / or gesturing on a touch-sensitive surface. Optional human-computer interaction functions include: creating web pages, drawing, word processing, creating electronic documents, playing games, video conferencing, instant messaging, sending and receiving emails, a call interface, playing digital video, playing digital music, and / or web browsing, etc. Executable instructions for performing the above human-computer interaction functions are configured / stored in one or more processor-executable computer program products or readable storage media.

[0045] This invention provides a container management method based on a container orchestration engine that runs on the aforementioned computer terminal. Figure 2 This is a flowchart of a container management method based on a container orchestration engine according to one embodiment of the present invention, such as... Figure 2 As shown, the method includes the following steps:

[0046] Step S21: Determine whether the target container has a target tag and obtain the determination result. The target tag is used to control the existence status of the target container.

[0047] Step S22: Use the container orchestration engine to manage the target container based on the judgment result.

[0048] The target container mentioned above can be a container or Pod deployed in a capacity orchestration engine. A Pod is the smallest deployable computing unit created and managed in a container orchestration engine. It can also be a collection of containers that share storage, network, and container runtime declarations. The contents of a Pod are co-located and can be scheduled together to run in a shared context.

[0049] The aforementioned Kubernetes container orchestration engine is used to manage containerized applications across multiple hosts in a cloud platform. The target tags mentioned above can be used to block unexpected tag deletion.

[0050] Through the above steps S21 to S22, by determining whether the target container has a target tag, a judgment result is obtained. The target tag is used to control the existence status of the target container. Then, the container orchestration engine manages the target container based on the judgment result, thereby avoiding the unexpected deletion of the container and achieving the technical effect of improving system stability. This solves the technical problem of poor system stability caused by the unexpected deletion of containers in the container orchestration engine.

[0051] Optionally, in step S22, managing the target container using the container orchestration engine based on the judgment result includes: performing a first process on the target container based on the judgment result to obtain a first result, wherein the first result is used to represent the target container's tolerance for key-value attribute data; performing a second process on the target container based on the judgment result to obtain a second result, wherein the second result is used to represent the target container's inclusion verification status; and performing a third process on the target container based on the judgment result to obtain a third result, wherein the third result is used to represent the target container's eviction processing status.

[0052] Specifically, the first process described above can be a tolerance check on the target container. The key-value attribute data can be a taint predefined on the worker node. Tolerance is one of the attributes of a Pod, which can prevent the Pod from being affected by the corresponding taint on the worker node during runtime and scheduling. If a worker node has a taint predefined, Pods that do not have tolerance set for that taint will respond according to the taint definition. For example, if the worker node has the following taint 1 defined, by performing a tolerance check on Pod1 on the worker node, it can be determined that Pod1 does not have a predefined tolerance for taint 1, and the Pod will be deleted. Based on the judgment result, a tolerance check is performed on the target container. When the target container has a tag that blocks unexpected deletion, the target container can block the tolerance check operation, thereby avoiding unexpected deletion of the target container due to the taint on the worker node.

[0053] The second process described above can be the management of target containers. Before managing existing containers during a Kubelet restart, containers that do not meet the management criteria need to be deleted. This process is called management verification. Only when a target container passes the management verification can the management process continue. Based on the judgment result, the target container is managed. If the target container has a tag that blocks unexpected deletion, it can block the management verification operation, thereby avoiding unexpected deletion of the target container due to non-compliance with management requirements during management verification.

[0054] The aforementioned third processing step can be used to handle target containers when worker node hardware resources are scarce. In related technologies, when the utilization rate of worker node hardware resources exceeds a preset value, Pod eviction is triggered, during which the Pod is deleted. Based on the judgment result, the target container is processed in this third step. If the target container has a tag that blocks unexpected deletion, the target container will stop executing the eviction process, thereby avoiding unexpected deletion of the target container due to insufficient hardware resources.

[0055] Based on the above optional embodiments, by using a container orchestration engine to manage target containers based on the judgment results, it is possible to effectively prevent the target containers from being deleted unexpectedly, thereby further ensuring the stability of the system during operation.

[0056] Optionally, the first processing of the target container based on the judgment result includes: in response to the existence of a target label in the target container, stopping the tolerance check on the target container and retaining the target container; in response to the absence of a target label in the target container, determining whether the target container has performed multiple preset change operations based on key-value attribute data, obtaining a target determination result, and deleting the target container based on the target determination result.

[0057] Specifically, by modifying the code related to worker node taints in the controller manager component, Pod deletion due to lack of tolerance for taints or tolerance timeouts can be avoided. If the target container has a target label, tolerance checks on the target container are stopped, and the target container is retained. If the target container does not have a target label, it is determined whether the target container has performed multiple preset change operations based on key-value attribute data, i.e., whether the target container can tolerate multiple preset taints of the worker node, thus obtaining the target determination result. If the target container cannot fully tolerate multiple preset taints of the worker node, a deletion operation is triggered; if the target container can fully tolerate multiple preset taints of the worker node, the minimum tolerance time among the multiple tolerances is further searched, and the target container is deleted after the minimum tolerance time has elapsed.

[0058] Based on the above optional embodiments, it is possible to effectively avoid the unexpected deletion of the target container due to a lack of tolerance for blemishes or tolerance timeout.

[0059] Optionally, the second processing of the target container based on the judgment result includes: in response to the target container not having a target label, performing a management verification on the target container based on a preset standard, and deleting the target container based on the management verification result; in response to the target container having a target label, performing status monitoring and resource allocation on the target container.

[0060] Specifically, when the Kubelet component restarts, it manages existing target containers. If the target container does not have a target tag, it performs management verification on the target container using management standards. If the management verification fails, the target container is unexpectedly deleted. If the target container has a target tag, it skips the management verification and directly performs the normal management process on the target container, such as enabling monitoring of the target container's status, managing the target container's resource allocation, and starting a separate thread to monitor the target container's health status.

[0061] Based on the above optional embodiments, it is possible to effectively avoid the unexpected deletion of target containers due to non-compliance with management standards.

[0062] Optionally, the third processing of the target container based on the judgment result includes: in response to the existence of a target label in the target container, controlling the container orchestration engine to stop transmitting the abnormal state information of the target container and retaining the target container.

[0063] Specifically, in related technologies, insufficient hardware resources on worker nodes trigger the eviction of target containers. The eviction process is as follows: When hardware resources exceed a preset value in the Kubelet component, the Kubelet component calls the apiserver to update the target device's working status to an abnormal state and changes the target container's working status recorded in etcd to an abnormal state. At this point, the Kubelet component deletes the target container, calling the apiserver to delete the interface corresponding to the target container and deleting the associated information recorded in etcd. Therefore, existing technologies inevitably lead to the unexpected deletion of target containers.

[0064] In this embodiment of the invention, when the hardware resource utilization rate in the Kubelet component exceeds a preset value, it is necessary to block the transmission of the abnormal state of the target container to prevent the scheduler component from allocating the resources corresponding to the target container to a new container. At the same time, when the target container has a target tag, the deletion operation is stopped, thereby enabling the retention of the target container when hardware resources are insufficient, and further ensuring the stability of the system.

[0065] Optionally, target key-value pairs are added during the creation of the target container, where the target key-value pairs are used to set the target label.

[0066] Specifically, target tags can be attached to key-value pairs on a Pod when it is created, and these key-value pairs can be added and modified at any time.

[0067] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0068] This embodiment also provides a container management device based on a container orchestration engine, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0069] Figure 3 This is a structural block diagram of a container management device based on a container orchestration engine according to one embodiment of the present invention, such as... Figure 3 As shown, the container management device 300 based on the container orchestration engine includes:

[0070] The judgment module 301 is used to determine whether the target container has a target tag and obtain a judgment result. The target tag is used to control the existence status of the target container.

[0071] Management module 302 is used to manage target containers based on the judgment results using the container orchestration engine.

[0072] Optionally, the management module 302 is further configured to: perform a first processing on the target container based on the judgment result to obtain a first result, wherein the first result is used to represent the tolerance of the target container for key-value attribute data; perform a second processing on the target container based on the judgment result to obtain a second result, wherein the second result is used to represent the management verification status of the target container; and perform a third processing on the target container based on the judgment result to obtain a third result, wherein the third result is used to represent the eviction processing status of the target container.

[0073] Optionally, the management module 302 is further configured to: in response to the existence of a target label in the target container, stop the tolerance check on the target container and retain the target container; in response to the absence of a target label in the target container, determine whether the target container has performed multiple preset change operations based on key-value attribute data, obtain the target determination result, and delete the target container based on the target determination result.

[0074] Optionally, the management module 302 is also used to: in response to the absence of a target label in the target container, perform management verification on the target container based on preset standards, and delete the target container based on the management verification result; in response to the presence of a target label in the target container, perform status monitoring and resource allocation on the target container.

[0075] Optionally, the management module 302 is also configured to: in response to the existence of a target label in the target container, control the container orchestration engine to stop transmitting abnormal state information of the target container and retain the target container.

[0076] Optionally, the container management device 300 based on the container orchestration engine further includes: a creation module 303, used to add target key-value pairs during the creation of the target container, wherein the target key-value pairs are used to set target tags.

[0077] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0078] Embodiments of the present invention also provide a non-volatile storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0079] Optionally, in this embodiment, the storage medium may be configured to store a computer program for performing the following steps:

[0080] S1, determine whether the target container has a target tag and obtain the determination result, where the target tag is used to control the existence status of the target container;

[0081] S2 utilizes a container orchestration engine to manage target containers based on the judgment results.

[0082] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0083] Embodiments of the present invention also provide a processor configured to run a computer program to perform the steps in any of the above method embodiments.

[0084] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0085] S1, determine whether the target container has a target tag and obtain the determination result, where the target tag is used to control the existence status of the target container;

[0086] S2 utilizes a container orchestration engine to manage target containers based on the judgment results.

[0087] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0088] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0089] In the several embodiments provided by this invention, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection can be through some interfaces; the indirect coupling or communication connection of units or modules can be electrical or other forms.

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

[0091] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0092] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, 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.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0093] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A container management method based on a container orchestration engine, characterized in that, include: During the creation of the target container, a target key-value pair is added, wherein the target key-value pair is used to set a target label, and the target label is a label that blocks unexpected deletion; Determine whether the target container has a target tag and obtain a determination result, wherein the target tag is used to control the existence status of the target container; Managing the target container using a container orchestration engine based on the judgment result includes: in response to the existence of the target label in the target container, stopping the tolerance check on the target container and retaining the target container; In response to the node agent component restarting and the target container having the target tag, the target container is subjected to status monitoring and resource allocation; In response to the node proxy component restarting and the target container not having the target tag, the target container is subjected to management verification based on preset standards, and the target container is deleted based on the management verification result; In response to the presence of the target label in the target container and the hardware resource utilization rate in the node proxy component exceeding a preset value, the container orchestration engine is controlled to stop transmitting the abnormal status information of the target container and retain the target container.

2. The container management method based on a container orchestration engine according to claim 1, characterized in that, The method further includes: In response to the absence of the target tag in the target container, it is determined whether the target container has performed multiple preset change operations based on the key-value attribute data to obtain a target determination result, and the target container is deleted based on the target determination result.

3. A container management device based on a container orchestration engine, characterized in that, include: The device is further configured to add target key-value pairs during the creation of the target container, wherein the target key-value pairs are used to set target tags, and the target tags are tags that block unexpected deletion. The judgment module is used to determine whether the target container has a target tag and obtain a judgment result, wherein the target tag is used to control the existence status of the target container; The management module is used to manage the target container based on the judgment result using the container orchestration engine, including: in response to the existence of the target label in the target container, stopping the tolerance check on the target container and retaining the target container; in response to the restart of the node agent component and the existence of the target label in the target container, performing status monitoring and resource allocation on the target container; in response to the restart of the node agent component and the absence of the target label in the target container, performing management verification on the target container based on preset standards, and deleting the target container based on the management verification result; in response to the existence of the target label in the target container and the hardware resource utilization rate in the node agent component exceeding a preset value, controlling the container orchestration engine to stop transmitting the abnormal status information of the target container and retaining the target container.

4. A non-volatile storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the container management method based on a container orchestration engine as described in any one of claims 1 to 2 at runtime.

5. A processor, characterized in that, The processor is used to run a program, wherein the program is configured to execute the container management method based on the container orchestration engine as described in any one of claims 1 to 2 at runtime.

6. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the container management method based on a container orchestration engine as described in any one of claims 1 to 2.

Images