A method for sequentially starting and destroying containers in a cloud native container group

Abstract

The present invention belongs to the field of computer technology, and specifically relates to a method for starting and destroying containers in a cloud native container group in sequence. The method includes the user passing in a general pod configuration, specifying the start and destruction order of the container when defining the container; sorting the containers according to the start order of the container identifiers, automatically adjusting the deployment plan, and deploying the application; the application is automatically started and destroyed according to the specified container identifier order. The present invention designs and implements a mechanism that deploys according to the order of specified containers so that the containers can be started and destroyed in the specified order. This method automatically adjusts the deployment plan, deploys the application, and finally the application is started and destroyed in the order specified by the user, and can be automatically started and destroyed according to the order of the container identifiers; one-click deployment, no need to understand the business logic, no need to manually change the container deployment information; as much as possible, the container creation process is not purely serialized, thereby improving creation efficiency.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology, and in particular relates to a method for sequentially starting and destroying containers in a cloud native container group. Background Art

[0002] With the maturity of virtualization technology and the prevalence of distributed frameworks, driven by open source communities and advancements in technologies like container technology, continuous delivery, and orchestration systems, as well as the microservices architecture and development philosophy, the concept of cloud native has emerged. Cloud native is a portmanteau of the words "cloud" and "native." "Cloud" refers to applications residing in the cloud, rather than in traditional data centers; "native" signifies that applications are designed from the outset with the cloud in mind, running optimally on the cloud and fully leveraging the elasticity and distributed nature of cloud platforms. Cloud native offers significant operational and maintenance advantages, making the migration of applications to the cloud a major trend.

[0003] Containers are the cornerstone of cloud-native application deployment and operation. Container orchestration, scheduling, communication, and service registration and discovery require a comprehensive system. Kubernetes, a leading cloud-native operating system, provides orchestration and management capabilities, making large-scale container deployment easy. Users can build application services across multiple containers, enabling cross-cluster scheduling, elastic scaling, and continuous health management of these containers. Kubernetes also provides a comprehensive container infrastructure by integrating networking, storage, security, monitoring, and other services.

[0004] Kubernetes uses container groups as the smallest deployment and scheduling unit. Containers within a container group typically have dependencies or call relationships with each other. In stateful applications, containers with dependencies must be started and terminated in a strict order. For example, the log collection container must be started before the business container and terminated after the business container to ensure log collection integrity.

[0005] Kubernetes version 1.18 attempted to introduce the sidecar feature, which marked specific containers as sidecars, ensuring they would start before regular containers and shut down after regular containers terminated. However, this feature was ultimately deprecated and has not been implemented in any Kubernetes release. Currently, the sidecar mechanism in pre-release versions of Kubernetes after 1.18 ensures that sidecar containers start before business containers and terminate after business containers. However, when multiple sidecar containers or multiple business containers are involved, the startup and termination order of containers of the same type cannot be guaranteed.

[0006] Currently, Kubernetes's own mechanisms cannot guarantee the normal startup and destruction order between containers. The sidecar feature, which was once proposed, can only classify containers into two categories: business containers and sidecar containers, and ensure the startup and destruction order between these two categories. However, when there are multiple sidecar containers or multiple business containers, the startup and destruction order of containers of the same type cannot be guaranteed. Existing solutions for setting the container startup order all require customized modifications based on the container's business logic, such as modifying the image or writing specific scripts, which require targeted manual changes. Summary of the Invention

[0007] To solve the above technical problems, the present invention provides a method for sequentially starting and destroying containers in a cloud-native container group. By only specifying the start-up and destruction order of each container, a deployment plan can be automatically set so that the containers are started and destroyed in the specified order. The provided application deployment method can automatically deploy sequential startup and destruction plans according to the set order of the containers, that is, automatically start and destroy them according to the order of the container identifiers. One-click deployment eliminates the need to understand business logic or manually change container deployment information, and minimizes the container creation process from being purely serialized, thereby improving creation efficiency.

[0008] The present invention is achieved by adopting the following technical solutions:

[0009] A method for sequentially starting and destroying containers in a cloud native container group, comprising:

[0010] The user passes in a common pod configuration and specifies the order in which containers are started and destroyed when defining them.

[0011] Sort containers according to the startup order of their container identifiers, automatically adjust deployment plans, and deploy applications.

[0012] Applications are automatically opened and destroyed in the order of specified container identifiers;

[0013] Among them, pod is a container group and the smallest scheduling unit in Kubernetes.

[0014] The present invention provides a method for sequentially starting and destroying containers in a cloud-native container group, which can automatically start and destroy containers according to the order of container identifiers; one-click deployment is required, without the need to understand business logic or manually change container deployment information; and the container creation process is minimized from being purely serialized to improve creation efficiency.

[0015] Furthermore, the method for automatically opening the containers according to the specified container identification sequence includes the following steps:

[0016] Sort the containers in the order in which they are started;

[0017] Access the sorted containers in sequence, adjust the container deployment plan, and deploy the application.

[0018] Get the startup probe or readiness probe function of the currently accessed container;

[0019] Determine whether the currently accessed container type is exec type;

[0020] If the currently accessed container type is exec type, then add or modify the postStart function to the current container and execute exec in a loop until the execution succeeds.

[0021] If the currently accessed container type is not the exec type, the current container is not the first container started, and the command of the current container is defined and modified. Before executing the command of the current container, it waits for the startup probe or readiness probe function of the previous container to execute successfully and then exits;

[0022] If the currently accessed container has no command, modify the postStart function of the previous container so that the current container waits for the startup probe or readiness probe function of the previous container to succeed before exiting.

[0023] Furthermore, if the currently accessed container type is not the exec type, the requested port in the TCP / HTTP probe is detected and assigned to port, and a check is made to see whether the next container exists. If the next container does not exist, the sequential startup of the containers is completed.

[0024] Furthermore, if the next container exists, check whether the command of the next container exists. If the next container does not have a command, add a postStart function to the current container and loop to check the port status until it exits the loop and enters the listening state. Then, access the next container in sequence.

[0025] Furthermore, if the command of the next container is checked to exist, the command definition of the next container is modified. First, the port status is detected in a loop until it exits the loop in the listening state. Then, the command of the current container is executed, and then the next container in the sorting order is accessed in sequence.

[0026] Furthermore, when the application is automatically started in the specified container ID sequence, the postStart function is blocked and the next container can only be created after successful execution.

[0027] Furthermore, when the application is automatically started in the specified container identification order, when a command is defined, when the detection is performed within the command, the current container creation runs concurrently with the previous container execution.

[0028] Furthermore, the application is automatically destroyed in the specified container identification order. The implementation mechanism of the container destruction order depends on the liveness probe and the preStop function of the life cycle. The method for automatically destroying the application in the specified container identification order includes the following steps:

[0029] Corresponding to sorting the containers according to the startup order of the container identifiers, obtaining the destruction order of the current container and obtaining the container definitions destroyed before the current container;

[0030] Get the liveness probe function of the previous container and determine whether the liveness probe type of the previous container is exec type;

[0031] If the liveness probe type of the previous container is exec, the liveness function of the previous container is changed, and the execution result of the previous container is written to the shared file at the same time;

[0032] Add a preStop function to the current container, and loop to check the result written to the shared file by the previous container until it is not 0 and exits the loop;

[0033] If the liveness probe type of the previous container is not exec, and the liveness probe type of the previous container is http / tcp, the loop checks the status of the requested port and exits the loop when it is no longer in the listening state.

[0034] Furthermore, if the liveness probe type of the previous container is not the exec type, the port requested in the http / tcp probe is detected and copied to port, a preStop function is added to the current container, and the port status is detected in a loop until it is no longer in the listening state and exits the loop.

[0035] Furthermore, when the application automatically destroys the containers in the specified order of identification, the termination time value of the container is set at the same time. The termination time value can be a relatively long time, such as one hour, to ensure that the container is not forced to exit due to timeout.

[0036] The present invention also includes a computer device comprising a memory and a processor, wherein the memory stores a computer program, and when the processor loads and executes the computer program, it implements the steps of a method for sequentially starting and destroying containers in a cloud native container group.

[0037] The present invention also includes a storage medium storing a computer program, which, when loaded and executed by a processor, implements the steps of the method for sequentially starting and destroying containers in a cloud native container group.

[0038] The technical solution provided by the present invention has the following beneficial effects:

[0039] The present invention provides a method for sequentially starting and destroying containers in a cloud-native container group, which can automatically start and destroy containers according to the order of container identifiers; one-click deployment is required, without the need to understand business logic or manually change container deployment information; and the container creation process is minimized from being purely serialized to improve creation efficiency.

[0040] These and other aspects of the present invention will become more readily apparent in the following description of the embodiments. It should be understood that the above general description and the following detailed description are merely exemplary and explanatory and are not intended to limit the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The accompanying drawings are used to provide a further understanding of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and do not constitute a limitation of the present invention. In the accompanying drawings:

[0042] Figure 1 This is a flowchart of sequential startup in a method for sequentially starting and destroying containers in a cloud native container group according to an embodiment of the present invention.

[0043] Figure 2 This is a flowchart of sequential destruction in a method for sequentially starting and destroying containers in a cloud native container group according to an embodiment of the present invention. DETAILED DESCRIPTION

[0044] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0045] Because Kubernetes's existing mechanisms cannot guarantee the proper startup and termination order between containers, the proposed sidecar feature can only classify containers into two categories: business containers and sidecar containers, ensuring a consistent startup and termination order between these two categories. However, if there are multiple sidecar containers or multiple business containers, the startup and termination order of containers of the same type cannot be guaranteed.

[0046] The existing solutions for setting the container startup order all require customized modifications based on the container's business logic, such as modifying the image or writing specific scripts, which require targeted manual changes.

[0047] To address this problem, the present invention proposes an application deployment method that can automatically deploy sequential startup and destruction solutions according to the set order of containers. The present invention provides a method for sequentially starting and destroying containers in a cloud native container group.

[0048] In the current state of application deployment, Kubernetes creates and starts common containers with the following three key points:

[0049] a) The order in which containers are created is the order in which they are defined in the pod;

[0050] b) After the container is created, command and postStart are started concurrently. That is, there is no order between the two. PostStart is likely to be called before command.

[0051] c) The command itself is started asynchronously, while the postStart method is blocking. Without postStart, the container starts the command and proceeds to create the next container, regardless of whether it has completed execution. With postStart, the container must wait for the postStart method to execute successfully before creating the next container. If postStart fails, the current container is destroyed and recreated.

[0052] In Kubernetes, containers also have a probe detection mechanism to determine the container status. Currently, the probes include readiness probes, liveness probes, and startup probes (Kubernetes 1, 17 and above). To ensure service availability during rolling upgrades and self-awareness of service exceptions during operation, you must define readiness+liveness probe functions, or startup+liveness probe functions.

[0053] Therefore, in combination with the above mechanism, the present invention designs and implements a mechanism for deploying containers according to a specified order so that the containers can be started and destroyed in the specified order.

[0054] See also Figure 1 and Figure 2 As shown, the present invention provides a method for sequentially starting and destroying containers in a cloud native container group, the method comprising:

[0055] The user passes in a common pod configuration and specifies the order in which containers are started and destroyed when defining them.

[0056] Sort containers according to the startup order of their container identifiers, automatically adjust deployment plans, and deploy applications.

[0057] Applications are automatically started and destroyed in the order of specified container IDs.

[0058] In this embodiment, pod is a container group, which is the smallest scheduling unit in Kubernetes. In Kubernetes, the container group as the smallest scheduling unit is called a pod.

[0059] The present invention provides a method for sequentially starting and destroying containers in a cloud-native container group, which can automatically start and destroy containers according to the order of container identifiers; one-click deployment is required, without the need to understand business logic or manually change container deployment information; and the container creation process is minimized from being purely serialized to improve creation efficiency.

[0060] See also Figure 1 As shown, the method for automatically opening an application according to a specified container identification sequence includes the following steps:

[0061] a) First, sort the container definitions in the order in which they are to be started.

[0062] b) Sequentially access container definitions and adjust container deployment plans.

[0063] c) Get the startup probe or readiness probe function of the container. If the type is exec, add or modify the postStart function of the container. The postStart function is defined as a loop logic that waits for the exec execution to succeed before exiting.

[0064] d) If the current container is not the first one started and a command is defined, modify its command to wait for the previous container's stratup or readiness probe function to succeed before exiting. If there is no command, modify the previous container's postStart to wait for the previous container's stratup or readiness probe to succeed before exiting.

[0065] Specifically, in this embodiment, the method for automatically opening the application according to the specified container identification sequence includes the following steps:

[0066] Sort the containers in the order in which they are started;

[0067] Access the sorted containers in sequence, adjust the container deployment plan, and deploy the application.

[0068] Get the startup probe or readiness probe function of the currently accessed container;

[0069] Determine whether the currently accessed container type is exec type;

[0070] If the currently accessed container type is exec type, then add or modify the postStart function to the current container and execute exec in a loop until the execution succeeds.

[0071] If the currently accessed container type is not the exec type, the current container is not the first container started, and the command of the current container is defined and modified. Before executing the command of the current container, it waits for the startup probe or readiness probe function of the previous container to execute successfully and then exits;

[0072] If the currently accessed container has no command, modify the postStart function of the previous container so that the current container waits for the startup probe or readiness probe function of the previous container to succeed before exiting.

[0073] In this embodiment, if the current access container type is not the exec type, the requested port in the TCP / HTTP probe is detected and assigned to port, and a check is made to see whether the next container exists. If the next container does not exist, the sequential startup of the containers is completed.

[0074] If the next container exists, check whether the command of the next container exists. If the next container does not have a command, add a postStart function to the current container and loop to check the port status until it exits the loop and enters the listening state. Then, access the next container in sequence.

[0075] If the command of the next container exists, the command definition of the next container is modified. First, the port status is detected in a loop until it exits the loop in the listening state. Then the command of the current container is executed, and then the next container in the sorted order is accessed in sequence.

[0076] It is important to note that not all scenarios use postStart to ensure the startup sequence. This is to improve efficiency. When the application automatically starts according to the specified container ID sequence, the postStart function is blocked and the next container can only be created after successful execution.

[0077] Since the container creation process involves pulling images, initializing the network, and mounting volumes, image pulling is time-consuming. If all operations are run serially, the entire pod startup process will be very long. Therefore, when defining a command, performing a check in the command allows container creation to run concurrently with the previous container execution, saving time.

[0078] See also Figure 2 As shown in the figure, corresponding to the guarantee of startup order, the implementation mechanism for ensuring the order of container destruction depends on the liveness probe and the preStop function of the life cycle.

[0079] In this embodiment, the application is automatically destroyed in the specified container identification order. The implementation mechanism of the container destruction order depends on the liveness probe and the preStop function of the life cycle. The method of automatically destroying the application in the specified container identification order includes the following steps:

[0080] Corresponding to sorting the containers according to the startup order of the container identifiers, obtaining the destruction order of the current container and obtaining the container definitions destroyed before the current container;

[0081] Get the liveness probe function of the previous container and determine whether the liveness probe type of the previous container is exec type;

[0082] If the liveness probe type of the previous container is exec, the liveness function of the previous container is changed, and the execution result of the previous container is written to the shared file at the same time;

[0083] Add a preStop function to the current container, and loop to check the result written to the shared file by the previous container until it is not 0 and exits the loop;

[0084] If the liveness probe type of the previous container is not exec, and the liveness probe type of the previous container is http / tcp, the loop checks the status of the requested port and exits the loop when it is no longer in the listening state.

[0085] In this embodiment, if the liveness probe type of the previous container is not the exec type, the port requested in the http / tcp probe is detected and copied to port, a preStop function is added to the current container, and the port status is cyclically detected until it is no longer in the listening state and the loop is exited.

[0086] When an application is automatically terminated in the specified container ID order, a termination grace period (TGRPS) value is set for the container. The TGRPS value can be a relatively long time, such as one hour, to ensure that the container is not forced to exit due to a timeout.

[0087] In one embodiment of the present invention, a computer device is provided, including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the steps in the above-mentioned method embodiments are implemented:

[0088] The user passes in a common pod configuration and specifies the order in which containers are started and destroyed when defining them.

[0089] Sort containers according to the startup order of their container identifiers, automatically adjust deployment plans, and deploy applications.

[0090] Applications are automatically started and destroyed in the order of specified container IDs.

[0091] The method for automatically opening an application in a specified container identification sequence includes the following steps:

[0092] Sort the containers in the order in which they are started;

[0093] Access the sorted containers in sequence, adjust the container deployment plan, and deploy the application.

[0094] Get the startup probe or readiness probe function of the currently accessed container;

[0095] Determine whether the currently accessed container type is exec type;

[0096] If the currently accessed container type is exec type, then add or modify the postStart function to the current container and execute exec in a loop until the execution succeeds.

[0097] If the currently accessed container type is not the exec type, the current container is not the first container started, and the command of the current container is defined and modified. Before executing the command of the current container, it waits for the startup probe or readiness probe function of the previous container to execute successfully and then exits;

[0098] If the currently accessed container has no command, modify the postStart function of the previous container so that the current container waits for the startup probe or readiness probe function of the previous container to succeed before exiting.

[0099] The application is automatically destroyed in the specified container identification order. The implementation mechanism of the container destruction order depends on the liveness probe and the preStop function of the life cycle. The method for automatically destroying the application in the specified container identification order includes the following steps:

[0100] Corresponding to sorting the containers according to the startup order of the container identifiers, obtaining the destruction order of the current container and obtaining the container definitions destroyed before the current container;

[0101] Get the liveness probe function of the previous container and determine whether the liveness probe type of the previous container is exec type;

[0102] If the liveness probe type of the previous container is exec, the liveness function of the previous container is changed, and the execution result of the previous container is written to the shared file at the same time;

[0103] Add a preStop function to the current container, and loop to check the result written to the shared file by the previous container until it is not 0 and exits the loop;

[0104] If the liveness probe type of the previous container is not exec, and the liveness probe type of the previous container is http / tcp, the loop checks the status of the requested port and exits the loop when it is no longer in the listening state.

[0105] In one embodiment of the present invention, a storage medium is further provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented:

[0106] The user passes in a common pod configuration and specifies the order in which containers are started and destroyed when defining them.

[0107] Sort containers according to the startup order of their container identifiers, automatically adjust deployment plans, and deploy applications.

[0108] Applications are automatically started and destroyed in the order of specified container IDs.

[0109] The method for automatically opening an application in a specified container identification sequence includes the following steps:

[0110] Sort the containers in the order in which they are started;

[0111] Access the sorted containers in sequence, adjust the container deployment plan, and deploy the application.

[0112] Get the startup probe or readiness probe function of the currently accessed container;

[0113] Determine whether the currently accessed container type is exec type;

[0114] If the currently accessed container type is exec type, then add or modify the postStart function to the current container and execute exec in a loop until the execution succeeds.

[0115] If the currently accessed container type is not the exec type, the current container is not the first container started, and the command of the current container is defined and modified. Before executing the command of the current container, it waits for the startup probe or readiness probe function of the previous container to execute successfully and then exits;

[0116] If the currently accessed container has no command, modify the postStart function of the previous container so that the current container waits for the startup probe or readiness probe function of the previous container to succeed before exiting.

[0117] The application is automatically destroyed in the specified container identification order. The implementation mechanism of the container destruction order depends on the liveness probe and the preStop function of the life cycle. The method for automatically destroying the application in the specified container identification order includes the following steps:

[0118] Corresponding to sorting the containers according to the startup order of the container identifiers, obtaining the destruction order of the current container and obtaining the container definitions destroyed before the current container;

[0119] Get the liveness probe function of the previous container and determine whether the liveness probe type of the previous container is exec type;

[0120] If the liveness probe type of the previous container is exec, the liveness function of the previous container is changed, and the execution result of the previous container is written to the shared file at the same time;

[0121] Add a preStop function to the current container, and loop to check the result written to the shared file by the previous container until it is not 0 and exits the loop;

[0122] If the liveness probe type of the previous container is not exec, and the liveness probe type of the previous container is http / tcp, the loop checks the status of the requested port and exits the loop when it is no longer in the listening state.

[0123] Those skilled in the art will appreciate that all or part of the processes in the above-described embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above-described methods. Any reference to memory, storage, database, or other media used in the embodiments provided herein may include at least one of non-volatile and volatile memory.

[0124] To summarize, the method of sequentially starting and destroying containers in a cloud-native container group in the present invention can automatically start and destroy containers according to the order of container identifiers; one-click deployment is required, and there is no need to understand business logic or manually change container deployment information; the container creation process is minimized from being purely serialized to improve creation efficiency.

[0125] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for sequentially starting and destroying containers in a cloud native container group, comprising: The user passes in a common pod configuration and specifies the order in which containers are started and destroyed when defining them. Sort containers according to the startup order of their container identifiers, automatically adjust deployment plans, and deploy applications. Applications are automatically opened and destroyed in the order of specified container identifiers; Among them, pod is a container group and the smallest scheduling unit in Kubernetes; The method for automatically opening an application according to a specified container identification sequence includes the following steps: Sort the containers in the order in which they are started; Access the sorted containers in sequence, adjust the container deployment plan, and deploy the application. Get the startup probe or readiness probe function of the currently accessed container; Determine whether the currently accessed container type is exec type; If the currently accessed container type is exec type, then add or modify the postStart function to the current container and execute exec in a loop until the execution succeeds. If the container type currently being accessed is not the exec type, the current container is not the first container started, and the command of the current container is defined and modified. Before executing the command of the current container, it waits for the startup probe or readiness probe function of the previous container to execute successfully and then exits; If the currently accessed container has no command, modify the postStart function of the previous container so that the current container waits for the startup probe or readiness probe function of the previous container to succeed before exiting.

2. The method for sequentially starting and destroying containers in a cloud native container group according to claim 1, characterized in that If the currently accessed container type is not the exec type, the requested port in the TCP / HTTP probe is detected and assigned to port, and the existence of the next container is checked. If the next container does not exist, the sequential startup of the containers is completed.

3. The method for sequentially starting and destroying containers in a cloud native container group according to claim 2, characterized in that: If the next container exists, check whether the command of the next container exists. If the next container does not have a command, add a postStart function to the current container and loop to check the port status until it exits the loop and enters the listening state. Then, access the next container in sequence.

4. The method for sequentially starting and destroying containers in a cloud native container group according to claim 3, characterized in that If the command of the next container exists, the command definition of the next container is modified. First, the port status is detected in a loop until it exits the loop in the listening state. Then the command of the current container is executed, and then the next container in the sorted order is accessed in sequence.

5. The method for sequentially starting and destroying containers in a cloud native container group according to claim 4, characterized in that: When the application is automatically started according to the specified container ID sequence, the postStart function is blocked and the next container can only be created after it is successfully executed.

6. The method for sequentially starting and destroying containers in a cloud native container group according to claim 5, characterized in that: When the application is automatically started in the specified container ID order, if a command is defined, when the detection is performed within the command, the current container creation runs concurrently with the previous container execution.

7. The method for sequentially starting and destroying containers in a cloud native container group according to claim 1 or 6, characterized in that: Applications are automatically destroyed in the specified order of container identifiers. The implementation mechanism of the container destruction order depends on the liveness probe and the preStop function of the lifecycle. The method for automatically destroying applications in the specified order of container identifiers includes the following steps: Corresponding to sorting the containers according to the startup order of the container identifiers, obtaining the destruction order of the current container and obtaining the container definitions destroyed before the current container; Get the liveness probe function of the previous container and determine whether the liveness probe type of the previous container is exec type; If the liveness probe type of the previous container is exec, the liveness function of the previous container is changed, and the execution result of the previous container is written to the shared file at the same time; Add a preStop function to the current container, and loop to check the result written to the shared file by the previous container until it is not 0 and exits the loop; If the liveness probe type of the previous container is not exec, and the liveness probe type of the previous container is http / tcp, the loop checks the status of the requested port and exits the loop when it is no longer in the listening state.

8. The method for sequentially starting and destroying containers in a cloud native container group according to claim 7, characterized in that: If the liveness probe type of the previous container is not exec, detect the port requested in the http / tcp probe and copy it to port, add a preStop function to the current container, and loop to detect the port status until it is no longer in the listening state and exits the loop.

9. The method for sequentially starting and destroying containers in a cloud native container group according to claim 8, characterized in that: When the application is automatically destroyed in the specified container ID order, the container termination time value is set at the same time.

Images