Container exit method and device

Abstract

The invention provides a container exiting method and device, and relates to the technical field of cloud computing. The method is applied to a container group, the container group comprises a plurality of containers, and the method comprises the following steps: a first container in the plurality of containers inquires an exit state of a second container in the plurality of containers, and the first container depends on the second container; and the first container exits according to the exit state of the second container. According to the scheme, the first container can obtain the exit state of the second container and exit according to the exit state of the second container, so that the first container can exit after the container on which the first container depends exits. According to the embodiment of the invention, a plurality of containers are supported to exit in sequence, and elegant exit among the plurality of containers is realized.

Description

[0001] This application claims the priority of the Chinese patent application filed with the China Patent Office on October 18, 2023, with application number 202311359924.6 and application name “Multi-container pod elegant exit method and system based on K8s”, the entire contents of which are incorporated by reference in this application. Technical Field

[0002] The present application relates to the field of cloud computing technology, and more specifically, to a container exit method and device. Background Art

[0003] A kubernetes (K8s) cluster can manage at least one pod, where each pod can include at least one container. When a pod terminates, the stop script (e.g., preStop) in the lifecycle of each container in the pod can be called. After the stop script of each container is executed, the K8s cluster can send a termination signal to the No. 1 process of each container.

[0004] However, how to achieve graceful exit between multiple containers is an urgent problem to be solved. Summary of the invention

[0005] The present application provides a container exit method and device, which can achieve graceful exit between multiple containers.

[0006] In a first aspect, a container exit method is provided. The method is applied to a container group, where the container group includes multiple containers. The method includes: a first container among the multiple containers queries an exit status of a second container among the multiple containers, where the first container depends on the second container; and the first container exits according to the exit status of the second container.

[0007] Through the above embodiment, the first container can obtain the exit status of the second container and exit according to the exit status of the second container, so that the first container can exit after the container on which the first container depends exits. The embodiment of the present application supports multiple containers to exit in sequence, realizing an elegant exit between multiple containers.

[0008] In combination with the first aspect, in some implementations of the first aspect, the first container exits according to the exit status of the second container, including: when the exit status of the second container is exit, the first container exits.

[0009] Through the above embodiment, the first container can exit when the second container exits. The embodiment of the present application supports multiple containers to exit in sequence, and realizes the graceful exit between multiple containers.

[0010] In combination with the first aspect, in some implementations of the first aspect, the method further includes: when the exit status of the second container is not exited, the first container queries the exit status of the second container.

[0011] Through the above embodiment, when the exit status of the second container is not exited, the first container can periodically query the shared storage module for the exit status of the second container. The above scheme implements the situation that the first container does not exit when the second container has not exited, so that the first container can exit after the container on which the first container depends exits. The embodiment of the present application supports multiple containers to exit in sequence, and realizes an elegant exit between multiple containers.

[0012] In combination with the first aspect, in some implementations of the first aspect, the container group further includes a shared storage module, which is used to record an exit status of each container in the multiple containers, wherein a first container in the multiple containers queries an exit status of a second container in the multiple containers, including: the first container in the multiple containers queries the shared storage module for an exit status of the second container in the multiple containers.

[0013] Through the above embodiment, the first container can query the shared storage module for the exit status of the second container. The above solution is easy to execute and has strong applicability. In addition, the above solution incurs less overhead in querying the exit status of the second container.

[0014] In combination with the first aspect, in some implementations of the first aspect, the container group belongs to a container cluster, and the container cluster also includes an exit management service module, wherein the method further includes: after the first container exits, the exit management service module modifies the exit status of the first container in the shared storage module.

[0015] Through the above embodiment, the exit management service module can maintain the exit status of each container stored in the shared storage module, so that the container on which the first container depends can accurately query the exit status of the first container.

[0016] In combination with the first aspect, in some implementations of the first aspect, the method further includes: when a container state running field corresponding to the first container in the container state of the container group does not exist, the exit management service module determines that the first container exits.

[0017] Through the above embodiment, the exit management service module can accurately determine whether the first container has exited according to whether the container status running field exists, thereby accurately maintaining the exit status of each container stored in the shared storage module.

[0018] In combination with the first aspect, in some implementations of the first aspect, the method further includes: the exit management service module obtains exit dependency information, where the exit dependency information is used to indicate a dependency relationship between the multiple containers; and the exit management service module configures information of the second container for the first container according to the dependency relationship.

[0019] Through the above embodiment, the exit management service module can configure the information of the container on which the container depends for the container according to the obtained dependency relationship, so that the container can be exited after the container on which the container depends exits. In addition, the above solution can automatically realize the exit of each container in the container group in sequence according to the dependency relationship.

[0020] In combination with the first aspect, in some implementations of the first aspect, the exit management service module obtains the exit dependency information, including: the exit management service module obtains the exit dependency information from the annotation information of the container group.

[0021] Through the above solution, each container can be exited according to the dependency relationship declared by the user in the annotation information, thereby improving the user experience.

[0022] In a second aspect, an embodiment of the present application provides a container ejection device, which includes a module for implementing the first aspect or any possible implementation manner of the first aspect.

[0023] In a third aspect, a computing device is provided, including a processor and a memory, wherein the processor is used to execute instructions stored in the memory so that the computing device executes the container exit method of the first aspect or any possible implementation of the first aspect.

[0024] In a fourth aspect, a computer program product comprising instructions is provided. When the instructions are executed by a computing device, the computing device executes the container exit method of the first aspect or any possible implementation of the first aspect.

[0025] In a fifth aspect, a computer-readable storage medium is provided, comprising computer program instructions. When the computer program instructions are executed by a computing device, the computing device executes the container exit method of the first aspect or any possible implementation of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 It is a schematic diagram of container exit dependency provided in an embodiment of the present application.

[0027] Figure 2 This is a schematic block diagram of a container cluster provided in an embodiment of the present application.

[0028] Figure 3It is a schematic flow chart of a container exit method provided in an embodiment of the present application.

[0029] Figure 4 It is a system diagram based on a cloud server system according to an embodiment of the present application.

[0030] Figure 5 It is a schematic block diagram of a container ejection device provided in an embodiment of the present application.

[0031] Figure 6 An architectural diagram of a computing device provided in an embodiment of the application.

[0032] Figure 7 It is a schematic diagram of the architecture of a computing device cluster provided in an embodiment of the present application.

[0033] Figure 8 It is a schematic diagram of a connection between two computing devices via a network provided in an embodiment of the present application. DETAILED DESCRIPTION

[0034] The technical solution in this application will be described below in conjunction with the accompanying drawings.

[0035] The present application will present various aspects, embodiments or features around a system that may include multiple devices, components, modules, etc. It should be understood and appreciated that each system may include additional devices, components, modules, etc., and / or may not include all of the devices, components, modules, etc. discussed in conjunction with the figures. In addition, combinations of these schemes may also be used.

[0036] In addition, in the embodiments of the present application, words such as "exemplary" and "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" in the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present concepts in a concrete way.

[0037] The business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0038] References to "one embodiment" or "some embodiments" etc. described in this specification mean that a particular feature, structure or characteristic described in conjunction with the embodiment is included in one or more embodiments of the present application. Thus, the phrases "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. appearing in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0039] Service mesh technology can separate the non-functional service governance logic in the distributed application of microservice architecture from the business process, and transfer the non-functional service governance logic to the sidecar module, which can act as a network proxy. For example, the non-functional service governance logic can include the use of the transport layer security (TLS) protocol to encrypt connections with other services, routing according to the hypertext transfer protocol (HTTP) and uniform resource locator (URL), gray release according to the content carried in the HTTP header, call chain tracking, traffic restriction and other capabilities.

[0040] In addition, service mesh technology provides each service with inter-service connectivity, security, traffic control, grayscale release, observation and other capabilities in a non-invasive manner, achieving lightweight business and infrastructure-based service governance. For example, service mesh can be implemented through the Istio system.

[0041] Service grid can be applied to a single container cluster scenario or to multiple container cluster scenarios. The container cluster here can be a K8s cluster, which can include a control node (also called a master node) and a controlled node (also called a node node).

[0042] Among them, the master node can be responsible for controlling the scheduling. For example, the master node can include a scheduling (kube-schedule) component, and the kube-schedule component can select a node for the newly created pod. A pod can include one or more containers, and a pod can be the smallest deployment unit in a container cluster. In other words, a pod can be regarded as a container group. Each microservice can be set or run in a pod. Microservices can also be called microservice applications, which can implement an independent business logic. Multiple microservices can provide corresponding business functions through calling and being called relationships.

[0043] Among them, the node node can be responsible for the workload. For example, the node node can include a container proxy module, which can also be called a kube-proxy component. The kube-proxy component can perform load balancing and evenly distribute the traffic received by the node node to each pod mounted under the node node.

[0044] When a pod is terminated, the stop script (such as preStop) in the life cycle of each container in the pod can be called. After the stop script of each container is executed, the K8s cluster can send a termination signal to the No. 1 process of each container. After receiving the termination signal, each container will exit.

[0045] The execution time of the stop script of each container in a pod and the total time for process 1 to receive and process the termination signal can be controlled by the termination grace period (terminationGracePeriodSeconds). Since the pod is terminated or the stop script is executed, if the termination grace period is exceeded and there are still containers in the pod that have not exited, the K8s cluster will force these containers to exit. For example, the K8s cluster can send a forced exit instruction, which instructs the container to exit.

[0046] The K8s cluster can configure the sleep time, for example, using the sleep command. The container with the configured sleep time will not exit before the sleep time expires.

[0047] For the service mesh implemented by the istio system, the K8s cluster can also configure the termination drain duration to control the waiting time before the sidecar module exits. The stop script in the sidecar module will not be executed immediately, but will wait for the termination drain duration to expire. After the termination drain duration expires, the stop script execution ends and a termination signal is sent to process No. 1 of the container where the sidecar module is located, thereby realizing the exit of the sidecar module. This avoids the problem that after the sidecar module exits, the network requests of other business containers in the pod have no entity to proxy and fail.

[0048] However, the configuration of the sleep time and the termination period depends on the experience of the technicians. In the actual process, the execution of the exit process may be abnormal. In abnormal cases, the container that needs to be exited first may not be exited, and the container that is configured with the sleep time or the termination period will execute the exit process normally, and exit before the container that should have exited first, resulting in a failure.

[0049] In some related technical solutions, the stop script in the sidecar module can detect the number of active connections. If the number of active connections reaches zero, the stop script execution ends and a termination signal is sent to process No. 1 of the container where the sidecar module is located. However, in the case of misdetection of the number of active connections, this solution may result in the sidecar module exiting before the business is completed.

[0050] In other related technical solutions, the stop script in the sidecar module can detect the number of processes in the non-sidecar container. If the number of processes reaches zero, the stop script execution ends and a termination signal is sent to process No. 1 of the container where the sidecar module is located. However, this solution relies on opening up the namespaces of each container process in the container group, which poses a security risk.

[0051] Figure 1 Schematic diagram of container exit dependency provided in the embodiment of the present application. It should be noted that: Figure 1 This is only an example and does not constitute a limitation of the present application. For example, the present application may be applicable to more or fewer containers, and the present application may be applicable to any dependency relationship between multiple containers.

[0052] See also Figure 1 , container 130 depends on container 120, and container 120 depends on container 110 and container 140. Container 110, container 120, container 130, and container 140 may belong to a container group.

[0053] As an example of a specific scenario, container 130 can be responsible for proxying network requests for a container group, and traffic in and out of the container group needs to be processed by container 130 first. Container 120 can be responsible for maintaining a long link with the database. Container 110 and container 140 are business containers used to handle specific businesses. The operation of container 110 and container 140 depends on container 120 and container 130, and the operation of container 120 depends on container 130. When the container group terminates, container 110 and container 140 need to exit first, then container 120 exits, and then container 130 exits. If container 130 that proxies network requests exits first or container 120 that maintains the database connection exits first, the processing of network requests by container 110 and container 140 will be impaired.

[0054] The above contents are only examples, and the containers 110 to 140 may also be other containers. Figure 1 Just as an example, the present application may also be applicable to more or fewer containers, and the present application may also be applicable to containers with other dependencies.

[0055] As mentioned earlier, how to achieve graceful exit between multiple containers is an urgent problem to be solved.

[0056] Figure 2 It is a schematic block diagram of a container cluster 200 provided in an embodiment of the present application.

[0057] The container cluster 200 may include a container group 210. In some optional implementations, the container cluster 200 may also include an exit service management module 220. The container group 210 may be one or more. In other words, the container cluster 200 may include at least one container group. The container cluster 200 may be a K8s cluster or other container management platform, which is not limited in this application.

[0058] The container group 210 may include multiple containers. Exemplarily, the container group 210 may include a first container 211 and a second container 212. However, the present application is not limited to this, and the container group 210 may also include more containers, for example, the container group 210 may also include a third container. The first container 211 may be one container or multiple containers. The second container 212 may be one container or multiple containers.

[0059] The container group 210 may further include a shared storage module 213, which may be used to record the exit status of each container in the plurality of containers in the container group 210. For example, the exit status of the first container 211 is not exited, and the exit status of the second container 212 is exited.

[0060] The containers in the container group 210 can access the shared storage module 213. For example, the first container 211 in the container group 210 queries the shared storage module 213 for the exit status of the second container 212. The exit management service module 220 can access the shared storage module 210. For example, the exit management service module 220 can modify the exit status of the first container 211 in the shared storage module 210. The exit management service module 220 can manage the containers in the container group 210. For example, the exit management service module 220 can inject a stop script into the first container 211 or the second container 212 in the container group 210.

[0061] Figure 3 300 is a schematic flow chart of a container exit method 300 provided in an embodiment of the present application. The method 300 can realize an elegant exit between multiple containers. The method 300 can be applied to the container group 210. Figure 3 Method 300 is introduced.

[0062] S310: A first container 211 among the multiple containers queries an exit status of a second container 212 among the multiple containers.

[0063] The first container 211 may depend on the second container 212. The first container 211 may be any one of a plurality of containers.

[0064] Exemplarily, the first container 211 can read the exit status of the second container 212 in the shared storage module 213. It should be noted that the second container 212 can be one container or multiple containers. In some optional embodiments, the second container 212 is the container on which all the first container 211 depends.

[0065] The first container 211 may be dependent on the second container 212. The term "dependent" may mean that the first container 211 needs to exit after the second container 212 exits. In other words, if the second container 212 does not exit, the first container 211 does not exit.

[0066] Exemplarily, S310 may be executed by a stop script (eg, preStop) in the first container 211 . For example, the stop script in the first container 211 may read the exit status of the second container 212 stored in the shared storage module 213 .

[0067] In some other optional embodiments, the first container 211 may initiate a network request query to the exit management service module 220 to query the exit status of the second container 212 in the multiple containers. Specifically, the stop script in the first container 211 may initiate a network request query to the exit management service module 220. The exit management service module 220 may send the exit status of the second container 212 to the first container 211 in response to the request.

[0068] S320, the first container 211 exits according to the exit status of the second container 212.

[0069] Exemplarily, S320 may be executed by a stop script (e.g., preStop) in the first container 211. For example, when the exit status of the second container 212 is exit, the stop script in the first container 211 is executed and a termination signal is sent to process No. 1 of the first container 211, and the termination signal is used to instruct the first container 211 to exit. For another example, when the exit status of the second container 212 is not exit, the stop script in the first container 211 continues to execute.

[0070] It is understandable that method 300 is described by taking a container (first container 211) and a container (second container 212) on which the container depends as an example, and the present application is not limited to multiple containers, where only one container executes the above method 300. Any container in the multiple containers can execute the above method 300. When all containers execute the above method 300, all containers exit in the order of dependency. For example, see Figure 1 , the containers 110 to 140 can be prepared according to the above method 300 and Figure 1 Specifically, when container 110 and container 140 have both exited, container 120 can exit; when container 120 has exited, container 130 can exit.

[0071] Through the above embodiment, the first container 211 can obtain the exit status of the second container 212 and exit according to the exit status of the second container 212, so that the first container 211 can exit after the container on which the first container 211 depends exits. The embodiment of the present application supports multiple containers to exit in sequence, and realizes an elegant exit between multiple containers.

[0072] Optionally, in some other implementation scenarios of the above embodiment, S320 includes: when the exit status of the second container 212 is exit, the first container 211 exits.

[0073] Through the above embodiment, the first container 211 can exit when the second container 212 exits. The embodiment of the present application supports multiple containers to exit in sequence, and realizes graceful exit between multiple containers.

[0074] Optionally, in some other implementation scenarios of the above embodiment, the method 300 further includes: when the exit status of the second container 212 is not exited, the first container 211 queries the exit status of the second container 212 .

[0075] When the first container 211 finds that the exit status of the second container 212 is not exited, the first container 211 can query the exit status of the second container 212 after a preset time. For example, the preset time can be set to 5 seconds. In this way, if the first container 211 finds that the exit status of the second container 212 is exited, the first container 211 can exit. If the first container 211 finds that the exit status of the second container 212 is not exited, the query is performed again after 5 seconds.

[0076] The above solution can also be understood as the first container 211 cyclically queries the exit status of the second container 212 with a preset time as a cycle. If the exit status of the second container 212 is exited, the cycle is terminated and the first container 211 exits. If the exit status of the second container 212 is not exited, the cycle continues and the exit status of the second container 212 is continuously queried in the next cycle.

[0077] The embodiment of the first container 211 querying the exit status of the second container 212 can refer to the aforementioned embodiment of S310, which is not described in detail here.

[0078] Through the above embodiment, when the exit status of the second container 212 is not exited, the first container 211 can periodically query the shared storage module 213 for the exit status of the second container 212. The above scheme implements that when the second container 212 is not exited, the first container 211 does not exit, so that the first container 211 can exit after the container on which the first container 211 depends exits. The embodiment of the present application supports multiple containers to exit in sequence, and realizes an elegant exit between multiple containers.

[0079] Optionally, in some other implementation scenarios of the above embodiments, the container group 210 further includes a shared storage module 220, which is used to record the exit status of each container in the multiple containers, wherein S310 includes: a first container 211 in the multiple containers queries the shared storage module 220 for the exit status of a second container 212 in the multiple containers.

[0080] Exemplarily, the shared storage module 220 may be added by the exit management service module 220. The shared storage module 220 may also be called a storage volume, and the present application does not limit the name of the shared storage module 220.

[0081] Through the above embodiment, the first container 211 can query the shared storage module 220 for the exit status of the second container 212. The above solution is easy to execute and has strong applicability. In addition, the above solution inquires about the exit status of the second container 212 with low overhead.

[0082] Optionally, in some other implementation scenarios of the above embodiments, the container cluster 200 further includes an exit management service module 220, wherein the method 300 further includes: after the first container 211 exits, the exit management service module 220 modifies the exit status of the first container 211 in the shared storage module 213.

[0083] The exit management service module 220 may maintain the exit status of each container stored in the shared storage module 213. For example, the exit information of the first container 211 may be recorded in the shared storage module 213.

[0084] It should be noted that the present application does not limit the specific name of the exit management service module 220. For example, the exit management service module 220 may also be called a termination controller.

[0085] In some optional embodiments, the exit management service module 220 may use an informer mechanism to watch the container group 210. The informer mechanism is a client cache mechanism provided by the container cluster. Through the informer mechanism, the exit management service module 220 can query, subscribe, and modify resources in the container cluster 200.

[0086] Exemplarily, the exit management service module 220 may obtain the exit status of the first container 211 by observing the container group 210 , and after the first container 211 exits, update the exit status of the first container 211 in the shared storage module 213 to “exit”.

[0087] Through the above embodiment, the exit management service module 220 can maintain the exit status of each container stored in the shared storage module 213, so that the container on which the first container 211 depends can accurately query the exit status of the first container 211.

[0088] Optionally, in some other implementation scenarios of the above embodiments, the method 300 further includes: when the container state running field corresponding to the first container 211 in the container state of the container group 210 does not exist, the exit management service module 220 determines that the first container 211 exits.

[0089] The container cluster 200 may maintain the container status (ContainerStatus) of the container group 210. After the first container 211 exits, the container cluster 200 may delete the container state running (ContainerStateRunning) field corresponding to the first container 211 in the container status.

[0090] Through the above embodiment, the exit management service module 220 can accurately determine whether the first container 211 is exited by whether the container status running field exists, thereby accurately maintaining the exit status of each container stored in the shared storage module 213.

[0091] Optionally, in some other implementation scenarios of the above embodiments, the method 300 also includes: the exit management service module 220 obtains exit dependency information, where the exit dependency information is used to indicate the dependency relationship between the multiple containers; and the exit management service module 220 configures the information of the second container 212 for the first container 211 according to the dependency relationship.

[0092] Exemplarily, the exit dependency information may be used to indicate Figure 1 Dependencies shown.

[0093] It should be noted that the first container 211 depends on the second container 212. Therefore, the exit management service module 220 configures the information of the second container 212 for the first container 211 according to the dependency relationship, which can be understood as the exit management service module 220 notifying or notifying the first container 211 of the information of the container on which the first container 211 depends.

[0094] In some optional embodiments, the exit management service module 220 can add an exit finalizer to the container in the container group 210. In this way, when the container group 210 terminates, the exit process of the container group 210 can be processed by the exit management service module 220. Among them, when the container group 210 configured with the exit finalizer terminates, the container group 210 can be deleted only after the exit management service module 220 removes the information of the exit finalizer. The mechanism of the exit finalizer realizes that the exit process is processed by the exit management service module 220.

[0095] Exemplarily, the exit management service module 220 can inject a stop script (e.g., preStop) into the container. A stop script hook in a container can cyclically access the shared storage module 213 to query whether the container on which the container depends has exited. In other words, the exit management service module 220 can configure the information of the second container 212 for the first container 211 according to the dependency relationship by injecting a stop script that can query the exit status of the second container 212 into the container.

[0096] In other words, the exit management service module 220 can parse the exit dependency information and add a stop script for each container. In some optional embodiments, the injection stop script can be executed when the container group 210 goes online. However, this application is not limited to this, and the injection stop script can also be performed at other times.

[0097] Through the above embodiment, the exit management service module 220 can configure the information of the container on which the container depends for the container according to the obtained dependency relationship, so that the container can be exited after the container on which the container depends exits. In addition, the above solution can automatically realize the exit of each container in the container group 210 in sequence according to the dependency relationship.

[0098] Optionally, in some other implementation scenarios of the above embodiment, the exit management service module 220 obtains the exit dependency information, including: the exit management service module 220 obtains the exit dependency information from the annotation information of the container group 210 .

[0099] It is understandable that the user may declare the exit dependency information in the annotation information of the container group 210 . In this way, the exit management service module 220 may obtain the exit dependency information in the annotation information of the container group 210 .

[0100] Through the above solution, each container can be exited according to the dependency relationship declared by the user in the annotation information, thereby improving the user experience.

[0101] In some optional real-time modes, the exit management service module 220 may check whether it is necessary for the exit management service module 220 to control the exit of each container in the container group 210. If necessary, the exit management service module 220 may inject an exit destructor into the container group 210, and the exit destructor is used to allow the exit management service module 220 to intervene in the processing when the container group 210 exits. The exit management service module 220 may insert a stop script into each container of the container group 210, and the stop script is used to block the exit of the container corresponding to the stop script until the container on which the container depends exits, and then the container can exit. After the exit management service module 220 inserts the stop script, the exit management service module 220 may periodically write the exit status of each container to the shared storage module 213.

[0102] Figure 4 It is a system diagram based on a cloud server system according to an embodiment of the present application.

[0103] like Figure 4 As shown, the cloud management platform 410 is used to manage the infrastructure that provides multiple cloud services, and the infrastructure includes multiple cloud data centers, each cloud data center includes multiple cloud servers, and each cloud server includes cloud service resources to provide corresponding cloud services to tenants. For example, cloud service resources may include one or more container clusters 200. One or more container clusters 200 may apply a cloud native service grid.

[0104] The cloud management platform 410 provides an access interface (such as an interface or an application program interface (API)). The tenant can operate the client remote access access interface to register a cloud account and password on the cloud management platform and log in to the cloud management platform. After the cloud management platform successfully authenticates the cloud account and password, the tenant can further pay to select and purchase a virtual machine with specific specifications (processor, memory, disk) on the cloud management platform. After the payment is successful, the cloud management platform provides the remote login account and password of the purchased virtual machine. The client can remotely log in to the virtual machine and install and run the tenant's application in the virtual machine. The tenant of the cloud service can be an individual, enterprise, school, hospital, administrative agency, etc.

[0105] The functions of the cloud management platform 410 include, but are not limited to, user console, computing management service, network management service, storage management service, authentication service, and image management service. The user console provides an interface or API to interact with tenants, the computing management service is used to manage servers running virtual machines and containers and bare metal servers, the network management service is used to manage network services (such as gateways, firewalls, etc.), the storage management service is used to manage storage services (such as data bucket services), the authentication service is used to manage tenant accounts and passwords, and the image management service is used to manage virtual machine images. Tenants can use the client 430 to log in to the cloud management platform 410 through the Internet 420 to manage the rented cloud services.

[0106] Exemplarily, the cloud server system may be a platform as a service (PaaS) system, a serverless system or other systems, etc. The present application does not limit the specific form of the cloud server system.

[0107] The method embodiments of the present application are described in detail above. Figures 5 to 8 The device embodiment of the embodiment of the present application is described. The device embodiment corresponds to the method embodiment, so the parts that are not described in detail can refer to the previous method embodiments. The device can implement any possible implementation method of the above method.

[0108] Figure 5 is a schematic block diagram of a container exit device 500 provided in an embodiment of the present application. The device 500 can be applied to a container group 210, and the container group 210 can include multiple containers, wherein the multiple containers can include: a first container 211, used to query the exit status of a second container 212 in the multiple containers, the first container 211 depends on the second container 212; the first container 211 is also used to exit according to the exit status of the second container 212.

[0109] In some optional embodiments, the first container 211 is specifically used for: when the exit state of the second container 212 is exit, the first container 211 exits.

[0110] In some optional embodiments, when the exit status of the second container 212 is not exited, the first container 211 is also used to query the exit status of the second container 212 .

[0111] In some optional embodiments, the container group 210 further includes: a shared storage module 213, which is used to record the exit status of each container in the multiple containers; wherein the first container 211 is specifically used to query the shared storage module 213 for the exit status of the second container 212 in the multiple containers.

[0112] In some optional embodiments, the container group 210 belongs to a container cluster 200 , and the container cluster 200 further includes: an exit management service module 220 , which is used to modify the exit status of the first container 211 in the shared storage module 213 after the first container 211 exits.

[0113] In some optional embodiments, when the container state running field corresponding to the first container 211 in the container state of the container group 210 does not exist, the exit management service module 220 is further used to determine that the first container 211 exits.

[0114] In some optional embodiments, the exit management service module 220 is further used to obtain exit dependency information, where the exit dependency information is used to indicate the dependency relationship between the multiple containers; the exit management service module 220 is further used to configure the information of the second container 212 for the first container 211 according to the dependency relationship.

[0115] In some optional embodiments, the exit management service module 220 is specifically used to obtain the exit dependency information from the annotation information of the container group 210 .

[0116] Specifically, the specific implementation of various operations executed by the device 500 in the container exit method 300 can refer to the description of the relevant contents in the above method embodiment, which will not be repeated here.

[0117] Among them, the first container 211, the second container 212, the shared storage module 213 and the exit management service module 220 can all be implemented by software, or can be implemented by hardware. Exemplarily, the implementation of the first container 211 is described below by taking the first container 211 as an example. Similarly, the implementation of the second container 212, the shared storage module 213 and the exit management service module 220 can refer to the implementation of the first container 211.

[0118] As an example of a software functional unit, the first container 211 may include code running on a computing instance. Among them, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above-mentioned computing instance may be one or more. For example, the first container 211 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region (region) or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including a data center or multiple data centers with close geographical locations. Among them, usually a region may include multiple AZs.

[0119] Similarly, multiple hosts / virtual machines / containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

[0120] As an example of a hardware functional unit, the first container 211 may include at least one computing device, such as a server, etc. Alternatively, the first container 211 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0121] The multiple computing devices included in the first container 211 can be distributed in the same region or in different regions. The multiple computing devices included in the first container 211 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the first container 211 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0122] It should be noted that, in other embodiments, the first container 211 can be used to execute any step in the container exit method, and the exit management service module 220 can be used to execute any step in the container exit method. The steps that the first container 211 and the exit management service module 220 are responsible for implementing can be specified as needed. The first container 211 and the exit management service module 220 respectively implement different steps in the container exit method to achieve all the functions of the container exit device 500.

[0123] The present application also provides a computing device 600. Figure 6 As shown, computing device 600 includes: bus 602, processor 604, memory 606 and communication interface 608. Processor 604, memory 606 and communication interface 608 communicate through bus 602. Computing device 600 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in computing device 600.

[0124] The bus 602 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 The bus 602 may include a path for transmitting information between various components of the computing device 600 (eg, the memory 606, the processor 604, and the communication interface 608).

[0125] The processor 604 may include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0126] The memory 606 may include a volatile memory, such as a random access memory (RAM). The memory 606 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0127] The memory 606 stores executable program codes, and the processor 604 executes the executable program codes to respectively implement the functions of the first container 211 and the exit management service module 220, thereby implementing the container exit method. That is, the memory 606 stores instructions for executing the container exit method 300.

[0128] The communication interface 608 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 600 and other devices or communication networks.

[0129] The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0130] like Figure 7 As shown, the computing device cluster includes at least one computing device 600. The same instructions for executing the container exit method 300 may be stored in the memory 606 in one or more computing devices 600 in the computing device cluster.

[0131] In some embodiments, the memory 606 of one or more computing devices 600 in the computing device cluster may also store partial instructions for executing the container exit method. In other words, the combination of one or more computing devices 600 may jointly execute instructions for executing the detection container exit method.

[0132] It should be noted that the memory 606 in different computing devices 600 in the computing device cluster may store different instructions, which are respectively used to execute part of the functions of the container exit device 500. That is, the instructions stored in the memory 606 in different computing devices 600 may implement the functions of one or more modules in the first container 211 and the exit management service module 220.

[0133] In some embodiments, one or more computing devices in the computing device cluster may be connected via a network, which may be a wide area network or a local area network, etc.

[0134] Figure 8 A possible implementation method is proposed. Figure 8 As shown, two computing devices 600A and 600B are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 606 in the computing device 600A stores instructions for executing the function of the first container 211. At the same time, the memory 606 in the computing device 600B stores instructions for exiting the function of the management service module 220.

[0135] Figure 8 The connection method between the computing device clusters shown may be based on the consideration that the container exit method provided in the present application requires a large amount of exit status maintenance, and therefore it is considered to hand over the functions implemented by the exit management service module 220 to the computing device 600B for execution.

[0136] It should be understood that Figure 8 The functions of the computing device 600A shown in FIG. 6A may also be completed by multiple computing devices 600. Similarly, the functions of the computing device 600B may also be completed by multiple computing devices 600.

[0137] In some embodiments, the memory 606 of one or more computing devices 600 in the computing device cluster may also respectively store partial instructions for executing the container exit method 300. In other words, the combination of one or more computing devices 600 may jointly execute the instructions for executing the container exit method 300.

[0138] The embodiment of the present application also provides a computer program product including instructions. The computer program product may be a software or program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes the above container exit method.

[0139] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute the above-mentioned container exit method.

[0140] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0141] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0142] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0143] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0144] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0145] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage media include: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memories (ROM), random access memories (RAM), magnetic disks or optical disks.

[0146] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A container exit method, characterized in that: The method is applied to a container group, the container group includes a plurality of containers, wherein the method comprises: A first container among the multiple containers queries an exit status of a second container among the multiple containers, the first container being dependent on the second container; The first container exits according to the exit status of the second container.

2. The method according to claim 1, characterized in that The first container exits according to the exit status of the second container, including: When the exit status of the second container is exit, the first container exits.

3. The method according to claim 1 or 2, characterized in that: Also includes: When the exit status of the second container is not exited, the first container queries the exit status of the second container.

4. The method according to any one of claims 1 to 3, characterized in that The container group further includes a shared storage module, and the shared storage module is used to record the exit status of each container in the multiple containers, wherein a first container in the multiple containers queries the exit status of a second container in the multiple containers, including: A first container among the multiple containers queries the shared storage module for an exit status of a second container among the multiple containers.

5. The method according to claim 4, characterized in that The container group belongs to a container cluster, and the container cluster further includes an exit management service module, wherein the method further includes: After the first container exits, the exit management service module modifies the exit status of the first container in the shared storage module.

6. The method according to claim 5, characterized in that Also includes: When the container state running field corresponding to the first container in the container state of the container group does not exist, the exit management service module determines that the first container exits.

7. The method according to claim 5 or 6, characterized in that: Also includes: The exit management service module acquires exit dependency information, where the exit dependency information is used to indicate a dependency relationship between the multiple containers; The exit management service module configures information of the second container for the first container according to the dependency relationship.

8. The method according to claim 7, characterized in that The exit management service module obtains the exit dependency information, including: The exit management service module obtains the exit dependency information from the annotation information of the container group.

9. A container ejection device, characterized in that: The device is applied to a container group, the container group includes a plurality of containers, wherein the plurality of containers include: A first container, used to query an exit status of a second container among the multiple containers, the first container being dependent on the second container; The first container is further used to exit according to the exit status of the second container.

10. The device according to claim 9, characterized in that The first container is specifically used for: When the exit status of the second container is exit, the first container exits.

11. The device according to claim 9 or 10, characterized in that When the exit status of the second container is not exited, the first container is further used to query the exit status of the second container.

12. The device according to any one of claims 9 to 11, characterized in that The container set also includes: A shared storage module, used to record the exit status of each container in the multiple containers; wherein the first container is specifically used to: The shared storage module is queried for an exit status of a second container among the plurality of containers.

13. The device according to claim 12, characterized in that The container group belongs to a container cluster, and the container cluster further includes: The exit management service module is used to modify the exit status of the first container in the shared storage module after the first container exits.

14. The device according to claim 13, characterized in that In a case where a container state running field corresponding to the first container in the container state of the container group does not exist, the exit management service module is further used to determine that the first container exits.

15. The device according to claim 13 or 14, characterized in that The exit management service module is further used to obtain exit dependency information, where the exit dependency information is used to indicate the dependency relationship between the multiple containers; The exit management service module is further used to configure information of the second container for the first container according to the dependency relationship.

16. The device according to claim 15, characterized in that The exit management service module is specifically used for: The exit dependency information is obtained from the annotation information of the container group.

17. A computing device cluster, characterized in that: comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 8.

18. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster is caused to perform the method according to any one of claims 1 to 8.

19. A computer-readable storage medium, characterized in that: The method comprises computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 8.

Images