Containerized service restarting method and device, electronic equipment and storage medium

Abstract

The invention discloses a containerized service restarting method and device, electronic equipment and a storage medium, and when the method is applied to a container management end, the method comprises the steps that the current running state of service in each container in a plurality of containers is acquired; the plurality of containers correspond to a plurality of service instances of the same service; for each container, if the current running state indicates that the service in the current container is to be restarted, sending an anti-registration request to a service registration center; the anti-registration request is used for indicating the service registration center to stop sending the service request to the current container; stopping the service process in the current container; restarting the service process in the current container based on the obtained service updating data; when it is detected that the service in the current container is restarted successfully, a registration request is sent to a service registration center; the registration request is used for indicating the current container of the service registration center to re-provide external service. According to the method and the device, the service restarting time can be shortened, the resource consumption is reduced, and the service restarting can be quickly, efficiently and safely completed in an energy-saving manner.

Description

Technical Field

[0001] The present application relates to the field of Internet technology, and in particular to a containerized service restart method, device, electronic device and storage medium. Background Art

[0002] In the current service deployment solutions, most of them use containerization methods such as k8s (short for kubernetes) to package applications and the systems and other environments they depend on, and deploy them as a whole based on containers.

[0003] When the data that a service depends on is updated, the service needs to be restarted to apply the updated data. In related technologies, it is necessary to restart the service by destroying the existing container and Pod (the smallest resource management unit of k8s) where the service is deployed, and then recreating a new Pod and container. This process usually takes several seconds to tens of seconds. For business areas that require frequent updates and restarts, such as navigation, and companies with large service scales, if they all go through the processes of Pod destruction, resource application, and reconstruction, the CPU and memory resources consumed are extremely large, and the long restart process and cycle may cause resources to be preempted, resulting in the inability to create new Pods and containers, thus affecting the normal operation of the business. Summary of the invention

[0004] In order to solve the problems of large resource consumption and long cycle of existing service restart, the present application provides a containerized service restart method, device, electronic device and storage medium:

[0005] According to a first aspect of the present application, a containerized service restart method is provided, which is applied to a container management end, and the method includes:

[0006] Get the current running status of the service in each container among multiple containers; multiple containers correspond to multiple service instances of the same service;

[0007] For each container, if the current running status indicates that the service in the current container is to be restarted, a deregistration request is sent to the service registration center; the deregistration request is used to instruct the service registration center to stop sending service requests to the current container;

[0008] Stop the service process in the current container;

[0009] Restart the service process in the current container based on the obtained service update data;

[0010] When it is detected that the service in the current container is restarted successfully, a registration request is sent to the service registration center; the registration request is used to instruct the service registration center that the current container provides services externally again.

[0011] According to a second aspect of the present application, a containerized service restart method is provided, which is applied to a service development end, and the method includes:

[0012] When it is determined that the service restart state has been entered, multiple containers of the deployed service are batched to obtain restart batch information; multiple containers correspond to multiple service instances of the service;

[0013] According to the restart batch information, the current running status of the service in each container is dynamically updated to the restart status; the restart status is used to instruct the container management end to perform a restart operation on the service process in the current container.

[0014] According to a third aspect of the present application, a containerized service restart device is provided, which is applied to a container management end, and the device includes:

[0015] The acquisition module is used to obtain the current running status of the service in each container in multiple containers; multiple containers correspond to multiple service instances of the same service;

[0016] A sending module is used to send a deregistration request to the service registration center for each container if the current running status indicates that the service in the current container is to be restarted; the deregistration request is used to instruct the service registration center to stop sending service requests to the current container;

[0017] The stop module is used to stop the service process in the current container;

[0018] The startup module is used to restart the service process in the current container based on the obtained service update data;

[0019] The sending module is also used to send a registration request to the service registration center when it is detected that the service in the current container is restarted successfully; the registration request is used to instruct the service registration center that the current container provides services to the outside again.

[0020] According to a fourth aspect of the present application, a containerized service restart device is provided, which is applied to a service development end, and the device includes:

[0021] The batch module is used to batch multiple containers of the deployed service to obtain restart batch information when it is determined that the service has entered the restart state; multiple containers correspond to multiple service instances of the service;

[0022] The update module is used to dynamically update the current running state of the service in each container to the restart state according to the restart batch information; the restart state is used to instruct the container management end to perform a restart operation on the service process in the current container.

[0023] According to a fifth aspect of the present application, an electronic device is provided, comprising a processor and a memory, wherein at least one instruction or at least one program is stored in the memory, and the at least one instruction or at least one program is loaded and executed by the processor to implement a containerized service restart method as in the first aspect or the second aspect.

[0024] According to the sixth aspect of the present application, a computer-readable storage medium is provided, in which at least one instruction or at least one program is stored, and the at least one instruction or at least one program is loaded and executed by a processor to implement the containerized service restart method of the first aspect or the second aspect.

[0025] According to a seventh aspect of the present application, a computer program is provided, which, when executed by a processor, implements the containerized service restart method of the first aspect or the second aspect.

[0026] The present application provides a containerized service restart method, device, electronic device, and storage medium, which have the following technical effects:

[0027] The container management end obtains the current running status of the service in each of the multiple containers. The current running status indicates that when the service in the current container is to be restarted, a deregistration request is sent to the service registration center to stop routing the service request to the current container. The container management end then stops the service process in the current container and restarts the service process based on the service update data. Finally, after the service restart is completed, an application is made to the service registration center for open access to complete the service restart. In this application, the container management end only needs to restart the service process in the container. Compared with the method of destroying and rebuilding Pods and containers in related technologies, this is a very lightweight operation, which can reduce the duration of service restart, reduce resource consumption, and ensure that the service traffic is not affected during the restart process. It can complete the service restart quickly, efficiently, safely, and energy-savingly. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the technical solutions and advantages in the embodiments of the present application or the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0029] Figure 1 is a schematic diagram of an application environment provided by an embodiment of the present application;

[0030] Figure 2 It is a flowchart of a containerized service restart method applied to a container management end provided in an embodiment of the present application;

[0031] Figure 3 This is a flowchart of restarting a service process in a current container provided by an embodiment of the present application;

[0032] Figure 4 It is a flowchart of a containerized service restart method applied to a service development end provided in an embodiment of the present application;

[0033] Figure 5 It is a schematic diagram of a process of batching multiple containers of a deployment service provided by an embodiment of the present application;

[0034] Figure 6 It is a schematic diagram of an interaction process provided by an embodiment of the present application;

[0035] Figure 7 This is a data flow diagram provided by an embodiment of the present application;

[0036] Figure 8 It is a block diagram of a containerized service restart device provided in an embodiment of the present application;

[0037] Fig. 9 It is a block diagram of another containerized service restart device provided in an embodiment of the present application;

[0038] Fig.10 It is a structural schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0039] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0040] It should be noted that the terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0041] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0042] Kubernetes (K8s for short): a container orchestration engine that supports automated deployment, large-scale scalability, and containerized management of services.

[0043] Pod: the unit of k8s resource management

[0044] Container: The unit that actually runs the business in k8s

[0045] See also Figure 1 , Figure 1 It is a schematic diagram of an application environment provided by an embodiment of the present application, which may include a container management end 01, at least one service development end 02 (such as service development end A, service development end B...service development end N), a service registration center 03 and at least one service call end 04 (such as service call end 1, service call end 2...service call end n); for each service development end 02, the service development end 02 can deploy its service as a container through the container management end 01. Usually, each service deploys N instances to load balance service requests, and each instance corresponds to a different container in the same Pod; for example, service development end A deploys three instances of service A in container 1, container 2 and container 3 in the same Pod respectively; when the service is running, the container management end 01 can manage the Pods and containers of services deployed by different service development ends 02; when the service call end 04 initiates a service request, the service registration center 03 is responsible for routing the service request to the corresponding container to process the service request.

[0046] In the related technology, when there is a service data update on the service development end 02, the container management end 02 needs to destroy the existing Pod and container, then reapply for resources and create new Pod and container to apply the updated service data. The process of Pod destruction, resource application, and reconstruction usually takes several seconds to tens of seconds. In this process, it is easy to encounter the problem that resources are preempted and new Pods and containers cannot be created, which in turn affects the normal operation of the business. For example, most navigation services and traffic query services in maps rely on road network data and mining data, so the service update frequency is very high, almost half a day or day level. If every time a service is updated, Pod destruction, resource application, reconstruction and other processes must be carried out, not only will it consume huge CPU and memory resources, but the long restart cycle will easily lead to container reconstruction failure and thus the normal operation of the service.

[0047] Based on this, an embodiment of the present application provides a containerized service restart method. When there is an update to the service, the container management end 01 can first stop the service process in the corresponding container, and notify the service registration center 04 to suspend service requests to the outside of the container route. Then the container management end 01 restarts the service process in the container based on the service update data. After the restart is successful, apply to the service registration center 04 to open the service route of the container. In this way, only very lightweight (process-level) operations are required, without consuming too many resources, and the service restart can be completed quickly, efficiently and safely without destroying and rebuilding pods and containers.

[0048] It should be noted that Figure 1 In the application scenario shown, the service call end 04 can be the service development end 02, or it can be a client such as a smart phone, a computer (desktop computer, tablet computer, laptop computer), an augmented reality (AR) / virtual reality (VR) device, a digital assistant, an intelligent voice interaction device (such as an intelligent speaker), an intelligent wearable device, an intelligent home appliance, a vehicle-mounted terminal, etc. In addition, Figure 1 The service deployment methods of each service development end are only examples. In actual scenarios, service development end A can also split service A and deploy it in multiple Pods. This application does not limit the service deployment method.

[0049] The following describes a specific embodiment of a containerized service restart method of the present application. In this embodiment, the containerized service restart method can be applied to a container management end. Figure 2 It is a flowchart of a containerized service restart method provided in an embodiment of the present application. The present application provides method operation steps as described in the embodiment or flowchart, but may include more or fewer operation steps based on conventional or non-creative labor. The order of steps listed in the embodiment is only one way of executing the steps among many orders, and does not represent the only order of execution. When the actual system or product is executed, it can be executed in sequence or in parallel according to the method shown in the embodiment or the accompanying drawings (for example, in a parallel processor or multi-threaded processing environment). Specifically, Figure 2 As shown, the method may include:

[0050] S201: Obtain the current running status of a service in each of a plurality of containers; the plurality of containers correspond to a plurality of service instances of the same service.

[0051] In the embodiment of the present application, multiple containers refer to multiple service instances of the same service, that is, the service development end containerizes its service in advance, and then the container management end can manage multiple containers corresponding to the service. Multiple containers can run on the same Pod to facilitate management by the container management end. The container management end can perform corresponding operations on each container based on the current running status of the service in each container in the multiple containers obtained.

[0052] In some possible embodiments, the current running state of the service in each container is stored in a service state storage area, which can be accessed by the service development end and the container management end. The container management end can read the current running state of the service in each container from the service state storage area according to a preset period.

[0053] Specifically, the container management end can periodically obtain the current running status of the service in each container based on the existing K8s component, namely the readiness detection probe; illustratively, the preset period can be a few minutes or hours.

[0054] In an embodiment of the present application, the current running status of the service in each of the above-mentioned containers may include but is not limited to the following states: creation state, normal running state, restart state and stop state; among which, the creation state represents when the Pod is initially created or before the service is started for the first time; the normal running state represents when the service is running normally and providing services to the outside world; the restart state represents that the service in the container is waiting to be restarted; and the stop state represents that the service in the container has stopped providing external services.

[0055] The current running status of the service in each of the above containers can be updated in the service status storage area by the service development end, and can also be updated in the service status storage area by the container management end.

[0056] S203: For each container, if the current running status indicates that the service in the current container is to be restarted, a deregistration request is sent to the service registration center; the deregistration request is used to instruct the service registration center to stop sending service requests to the current container.

[0057] In an embodiment of the present application, the container management end takes each container as the current container in turn, and then determines the current running state of the service in the current container; if the container management end obtains that the current running state of the service in the current container indicates that the service in the current container is to be restarted, that is, the current running state is a restart state, the container management end sends a de-registration request to the service registration center; here, the service registration center is mainly responsible for the routing of external service requests, that is, determining the service address corresponding to the domain name according to the domain name in the external service request, and then assigning the service request to the container corresponding to the service address for subsequent processing; when the current running state of the service in the current container indicates that its service is to be restarted, it means that the current container cannot process external service requests, so the container management end needs to send a de-registration request to the service center, and carry the identifier of the current container in the de-registration request, so that the service registration center can stop sending external service requests to the current container according to the identifier of the current container.

[0058] In some possible embodiments, the current running state indicating that the service in the current container is to be restarted may be written by the service development end into the service state storage area. Specifically, when the data on which the service depends is updated, the service development end may set the current running state of the service in the container corresponding to the service to the restart state in the service state storage area to instruct the container management end to perform a restart operation on the service process in the container.

[0059] S205: Stop the service process in the current container.

[0060] In the embodiment of the present application, after the container management end sends a deregistration request to the service registration center, it executes the operation of stopping the service process in the current container. Specifically, the container management end can gracefully stop the service process in the current container through the kill pid instruction; the function of kill pid is to send SIGTERM (this is the default signal sent by kill) to the process with the process number pid, which is a signal to end the process.

[0061] In some possible embodiments, the above restart state can be further subdivided into a first restart state, a second restart state and a third restart state; wherein the first restart state indicates that the service in the current container is to be restarted and access to the service in the current container is suspended; the second restart state indicates that the service in the current container is ready to restart, that is, it indicates that the service in the current container enters the restart state; the third restart state indicates that the service in the container is in the process of restarting;

[0062] Then, the above S203 may specifically include: when the current running state is the first restart state, the container management end sends a deregistration request to the service registration center; the above S205 may specifically include: when the current running state is updated from the first restart state to the second restart state, the service process in the current container is stopped. Here, both the first restart state and the second restart state can be updated by the service development end in the service state storage area.

[0063] Furthermore, before stopping the service process in the current container, the container management end may update the current running state of the service in the current container to a third restart state in the service state storage area to indicate that the service is in the process of restarting.

[0064] In the above embodiment, different restart states are used to distinguish services in different restart stages in the container. When it is confirmed that the service in the container has suspended access and is ready to restart, the container management end executes the restart operation of stopping the service process. This can avoid external service interruption and ensure the smooth restart of the service in the container.

[0065] S207: Restart the service process in the current container based on the obtained service update data.

[0066] In the embodiment of the present application, after suspending the external service of the current container, the container management end can obtain service update data and restart the service process in the current container based on the service update data.

[0067] In some possible embodiments, the above S207 may include: Figure 3 The following steps are shown:

[0068] S301: Acquire service update data published by the service development end from the service data storage area based on the service image startup file.

[0069] In this step, the service development end publishes the service update data to the service data storage area in advance; when the container management end restarts the service process in the container, it runs the service image startup file, and when the service image startup file runs, it can automatically pull the service update data from the service data storage area.

[0070] S303: Restarting the service process in the current container based on the service update data.

[0071] In this step, the container management end restarts the service process in the current container using the pulled service update data while running the service image startup file.

[0072] In the above embodiment, the container management end only needs to restart the service process in the container, which is a very lightweight operation compared to the method of destroying and rebuilding the Pod and container in the related art. Therefore, there is no need to consume too much CPU and memory resources of the container management end, and the restart process is less disturbed and the restart speed is fast, so the service restart can be completed efficiently and energy-savingly.

[0073] S209: When it is detected that the service in the current container is restarted successfully, a registration request is sent to the service registration center; the registration request is used to instruct the service registration center that the current container provides services externally again.

[0074] In an embodiment of the present application, the container management end can perform real-time detection on the restart process of the service in the current container. When it is detected that the service in the current container is successfully restarted, the container management end sends a registration request to the service registration center to indicate to the service registration center that the current container can provide services to the outside world again. The service registration center can allocate the service request to the current container again.

[0075] In summary, the containerized service restart method applied to the container management end provided in the embodiment of the present application is suitable for services that need to be frequently updated and restarted (such as hourly and daily levels). The operations involved in the entire restart process are process-level and do not involve the destruction and reconstruction of Pods and containers at all. It can reduce the duration of service restart and reduce resource consumption, and can complete the service restart quickly, efficiently, safely, and energy-savingly.

[0076] The following describes a specific embodiment of a containerized service restart method of the present application. In this embodiment, the containerized service restart method can be applied to the service development end; Figure 4 It is a flowchart of a containerized service restart method provided in an embodiment of the present application. The present application provides method operation steps as described in the embodiment or flowchart, but may include more or fewer operation steps based on conventional or non-creative labor. The order of steps listed in the embodiment is only one way of executing the steps among many orders, and does not represent the only order of execution. When the actual system or product is executed, it can be executed in sequence or in parallel according to the method shown in the embodiment or the accompanying drawings (for example, in a parallel processor or multi-threaded processing environment). Specifically, Figure 4 As shown, the method may include:

[0077] S401: When it is determined that the service restart state has been entered, multiple containers of the deployed service are batched to obtain restart batch information; the multiple containers correspond to multiple service instances of the service.

[0078] In the embodiment of the present application, when the data that the service depends on is updated, the service development end can initiate a service restart operation, and then determine to enter the service restart state. Since the service development end deploys multiple containers in the same Pod corresponding to multiple service instances of the service when deploying the service, the service development end can deploy the multiple containers in batches when restarting the service, and then restart the services in each container according to the batches.

[0079] Specifically, the service development end can enter the service restart state by running a lossless restart script. In the script, it can be specified that multiple containers of the deployed service are all containers to be restarted, and multiple containers are batched to obtain restart batch information. The restart batch information may include multiple batches to be restarted and the container identifier of each batch to be restarted.

[0080] Take the traffic query service in the map application as an example. Assuming that 50 service instances of the traffic query service are deployed in 50 containers respectively, the service development end can restart the traffic query service in the 50 containers in 5 batches. During the restart of each batch of containers, the container does not provide traffic query services to the outside world. The user's traffic query requests can be directed to the remaining 40 containers. This can ensure the normal operation of the traffic query service and achieve lossless traffic at the user layer.

[0081] S403: Dynamically update the current running state of the service in each container to a restart state according to the restart batch information; the restart state is used to instruct the container management end to perform a restart operation on the service process in the current container.

[0082] In an embodiment of the present application, the service development end can dynamically update the container identifier of the current batch to be restarted in the service status storage area according to the restart batch information, and the current running state of the service in the corresponding container is the restart state. When the container management end accesses the service status storage area, for the container whose current running state of the service in the container is the restart state, a restart operation is performed on the service process in the container.

[0083] In some possible embodiments, the above step S401 may specifically include the following: Figure 5 The following steps are shown:

[0084] S501: Determine the container to be restarted from the restart batch information.

[0085] In this step, the restart batch information includes multiple batches to be restarted, and the service development end sequentially uses each batch to be restarted as the current batch to be restarted, and uses the container in the current batch to be restarted as the current container to be restarted.

[0086] Specifically, in the above embodiment, after the container management end restarts the service in the container, it will send a service request to the service registration center to reopen the traffic to the outside world. In order to ensure that the service in the container is successfully restarted and reopened to the outside world, the service development end can confirm with the service registration center whether the services in the batch of containers in each current batch to be restarted are successfully restarted; when the service development end confirms from the service registration center that the services in the containers of the current batch to be restarted have been successfully restarted, it will determine the container of the next batch to be restarted from the restart batch information, and then use the container of the next batch to be restarted as the current container to be restarted, and repeat the subsequent steps until the restart of the services in all containers is completed.

[0087] S503: Set the current running state of the service in the container to be restarted to the first restart state.

[0088] In this step, in order to ensure the smooth restart of the service in the container and avoid service interruption to the outside world, the external access traffic of the service in the container must be suspended before the formal restart. Therefore, the service development end first sets the current running state of the service in the container to be restarted to the first restart state in the service state storage area, and instructs the container management end to suspend the reception of service requests for the container to be restarted through the first restart state.

[0089] S505: When it is confirmed from the service registration center that the current container to be restarted has stopped receiving service requests, the current running state of the service in the current container to be restarted is updated from the first restart state to the second restart state.

[0090] In this step, the service development end can confirm with the service registration center whether the current container to be restarted has suspended receiving service requests. If it is confirmed that the current container to be restarted has suspended receiving service requests, the current running status of the service in the current container to be restarted is updated from the first restart status to the second restart status. The second restart status is used to instruct the container management end to stop the service process in the current container to be restarted.

[0091] In the above embodiment, the service development end instructs the container management end to perform different operations by setting different restart states for the current container to be restarted. Only when the service development end confirms that the service in the current container to be restarted has suspended external access traffic and is ready to restart, the container management end is allowed to perform subsequent related operations of stopping the service process. This can ensure that user access is not affected and the smooth restart of the service is guaranteed. At the same time, the service development end will restart the services of the next batch to be restarted only after all the services in the containers of the current batch to be restarted have been successfully restarted. In this way, if the service restart fails, the cause of the failure can be discovered and handled in time, which can avoid allocating external service requests to containers that have not been successfully restarted, resulting in the inability to provide services.

[0092] In summary, the containerized service method provided in the embodiment of the present application is suitable for service development ends that need frequent updates and restarts (such as hourly and daily levels). By restarting multiple instances in batches, it can ensure that the service traffic is not affected during the restart process, thereby ensuring the normal operation of the business.

[0093] In the above embodiment, the service development end initiates the service restart, batches multiple containers, and dynamically updates the current running state of the service in each container to the restart state according to the restart batch information. The container management end only needs to perform corresponding restart operations according to different running states; in other possible embodiments, the container management end may also realize batching multiple containers and dynamically updating the current running state of the service in each container according to the restart batch information;

[0094] That is, in the embodiment of the containerized service restart method applied to the container management end of the present application, that is, before the above-mentioned step S201, the following steps can also be included: in response to the service restart message sent by the service development end, dynamically update the current running status of the service in each container.

[0095] Specifically, the service development end still initiates the service restart. The container management end can restart the services in multiple containers in batches according to the service restart message sent by the service development end, and dynamically update the current running status of the service in each container. The specific implementation can refer to the method of implementing batch and dynamic update by the service development end in the above embodiment, which will not be repeated here.

[0096] In the above embodiment, the restart operation involved in the service development end is transferred to the container management end for implementation. The service development end only needs to initiate a service restart to the container management end when there is a service data update, which can greatly save service maintenance costs and help the service development end focus on business development.

[0097] Combine the following Figure 6 The interactive process diagram shown and Figure 7The data flow diagram shown in the figure comprehensively introduces a containerized service restart method of the present application, so as to more clearly understand the role of the service development end, the container management end and the service registration center in the containerized service restart process. First, in S601, the service development end can obtain restart batch information for multiple containers deployed with services in batches when determining to enter the service restart state; secondly, in S603, the service development end dynamically updates the current running state of the service in each container to the restart state in the service status storage area according to the restart batch information; in S605, the container management end can obtain the current running state of the service in each container in the multiple containers from the service status storage area; in S607, if the current running state indicates that the service in the current container is to be restarted, the container management end sends a de-registration request to the service registration center; in actual applications such as Figure 7 As shown, the service development end can first run the restart script, and then update the service in the current container to be restarted to the first restart state. The container management end sends a deregistration request to the service registration center based on the first restart state; then, the service development end can confirm from the service registration center whether the current container to be restarted has been suspended from receiving service requests. When it is confirmed that the current container to be restarted has been suspended from receiving service requests, the current running state of the service in the current container to be restarted is updated from the first restart state to the second restart state; in S609, when the current running state is updated from the first restart state to the second restart state, the container management end stops the service process in the current container; in actual applications, as shown in FIG. Figure 7 As shown, the container management end can update the current running state of the service in the current container to be restarted to the third restart state, and then stop the service process; in S611, the container management end restarts the service process in the current container based on the obtained service update data; in S613, when the container management end detects that the service in the current container is successfully restarted, it sends a registration request to the service registration center to instruct the service registration center that the current container is providing services to the outside world again. In actual applications, Figure 7 As shown, the container management end restarts the service process in the container to be restarted, and then the service development end can confirm with the service registration center whether the services in the containers of the current batch to be restarted have been restarted successfully. When the service registration center confirms that the services in the containers of the current batch to be restarted have been restarted successfully, the services of the containers of the next batch to be restarted are restarted.

[0098] In summary, the containerized service restart method provided in the embodiment of the present application is suitable for services that need to be frequently updated and restarted (such as hourly and daily levels). The operations involved in the entire restart process are process-level, and do not involve the destruction and reconstruction of Pods and containers at all. It can reduce the duration of service restart and reduce resource consumption. By restarting multiple service instances in batches, it can ensure that service traffic is not affected during the restart process, and the service restart can be completed quickly, efficiently, safely, and energy-savingly.

[0099] The present application embodiment also provides a containerized service restart device, which is applied to a container management end, such as Figure 8 As shown, the containerized service restart device 80 includes:

[0100] The acquisition module 801 is used to obtain the current running status of the service in each container of the multiple containers; the multiple containers correspond to multiple service instances of the same service;

[0101] The sending module 802 is used to send a deregistration request to the service registration center for each container if the current running status indicates that the service in the current container is to be restarted; the deregistration request is used to instruct the service registration center to stop sending service requests to the current container;

[0102] Stop module 803, used to stop the service process in the current container;

[0103] A starting module 804 is used to restart the service process in the current container based on the obtained service update data;

[0104] The sending module 802 is also used to send a registration request to the service registration center when it is detected that the service in the current container is restarted successfully; the registration request is used to instruct the service registration center that the current container provides services externally again.

[0105] In some possible embodiments, the acquisition module 801 is also used to read the current running status of the service in each container from the service status storage area according to a preset period; the current running status of the service to be restarted in the current container is written into the service status storage area by the service development end.

[0106] In some possible embodiments, the sending module 802 is further used to send a deregistration request to the service registration center when the current running state is a first restart state; the first restart state indicates that the service in the current container is to be restarted and access to the service in the current container is suspended;

[0107] The stop module 803 is also used to stop the service process in the current container when the current running state is updated from the first restart state to the second restart state; the second restart state indicates that the service in the current container enters the restart state.

[0108] In some possible embodiments, the startup module 804 is further used to obtain service update data published by the service development end from the service data storage area based on the service image startup file; and restart the service process in the current container based on the service update data.

[0109] In some possible embodiments, the device also includes an update module for dynamically updating the current running status of the service in each container in response to a service restart message sent by the service development end; the service restart message indicates that the services in multiple containers are restarted in batches.

[0110] The present application embodiment also provides a containerized service restart device, which is applied to the service development end, such as Fig. 9 As shown, the containerized service restart device 90 includes:

[0111] The batch module 901 is used to batch multiple containers of the deployed service to obtain restart batch information when it is determined that the service restart state has been entered; multiple containers correspond to multiple service instances of the service;

[0112] The update module 902 is used to dynamically update the current running state of the service in each container to a restart state according to the restart batch information; the restart state is used to instruct the container management end to perform a restart operation on the service process in the current container.

[0113] In some possible embodiments, the update module 902 is further used to determine the current container to be restarted from the restart batch information; set the current running state of the service in the current container to be restarted to a first restart state; the first restart state instructs the container management end to suspend the current container to be restarted from receiving service requests; when it is confirmed from the service registration center that the current container to be restarted is suspended from receiving service requests, the current running state of the service in the current container to be restarted is updated from the first restart state to the second restart state; the second restart state instructs the container management end to stop the service process in the current container to be restarted.

[0114] In some possible embodiments, the update module 902 is further used to determine the next batch of containers to be restarted from the restart batch information when confirming from the service registration center that the service in the current batch of containers to be restarted is successfully restarted; and use the next batch of containers to be restarted as the current batch of containers to be restarted.

[0115] It should be noted that the device in the device embodiment and the method embodiment are based on the same inventive concept.

[0116] An embodiment of the present application provides an electronic device, which includes a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement the containerized service restart method provided in the above method embodiment.

[0117] Further, Fig.10A hardware structure diagram of an electronic device for implementing the containerized service restart method provided in an embodiment of the present application is shown. The electronic device may participate in constituting or include the containerized service restart device provided in an embodiment of the present application. Fig.10 As shown, the electronic device 100 may include one or more (1002a, 1002b, ..., 1002n are used to illustrate) processors 1002 (the processor 1002 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 1004 for storing data, and a transmission device 1006 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a power supply and / or a camera. It can be understood by those skilled in the art that Fig.10 The structure shown is only for illustration and does not limit the structure of the above electronic device. Fig.10 More or fewer components as shown, or with Fig.10 Different configurations shown.

[0118] It should be noted that the one or more processors 1002 and / or other data processing circuits described above may generally be referred to herein as "data processing circuits". The data processing circuits may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be incorporated in whole or in part into any of the other components in the electronic device 100 (or mobile device). As described in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0119] The memory 1004 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the containerized service restart method described in the embodiment of the present application. The processor 1002 executes various functional applications and data processing by running the software programs and modules stored in the memory 1004, that is, to implement the above-mentioned containerized service restart method. The memory 1004 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 1004 may further include a memory remotely arranged relative to the processor 1002, and these remote memories may be connected to the electronic device 100 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0120] The transmission device 1006 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the electronic device 100. In one example, the transmission device 1006 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one embodiment, the transmission device 1006 can be a radio frequency (Radio Frequency, RF) module, which is used to communicate with the Internet wirelessly.

[0121] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the electronic device 100 (or mobile device).

[0122] An embodiment of the present application further provides a computer-readable storage medium, which can be set in an electronic device to store at least one instruction or at least one program related to implementing a containerized service restart method in a method embodiment, and the at least one instruction or the at least one program is loaded and executed by the processor to implement the containerized service restart method provided in the above method embodiment.

[0123] Optionally, in this embodiment, the storage medium may be located in at least one of the multiple network servers of the computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0124] It should be noted that the above-mentioned sequence of the embodiments of the present application is for description only and does not represent the advantages and disadvantages of the embodiments. The above-mentioned specific embodiments of the present application are described. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0125] Each embodiment in this application is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and electronic device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0126] A person skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware or by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

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

Claims

1. A containerized service restart method, characterized in that: Applied to the container management end, the method includes: Obtain the current running status of a service in each of a plurality of containers; the plurality of containers correspond to a plurality of service instances of the same service; For each of the containers, if the current running state indicates that the service in the current container is to be restarted, a deregistration request is sent to the service registration center; the deregistration request is used to instruct the service registration center to stop sending service requests to the current container; Stop the service process in the current container; Restarting the service process in the current container based on the acquired service update data; When it is detected that the service in the current container is restarted successfully, a registration request is sent to the service registration center; the registration request is used to instruct the service registration center that the current container provides services externally again.

2. The containerized service restart method according to claim 1, characterized in that: The obtaining of the current running status of the service in each container of the multiple containers includes: According to a preset period, the current running state of the service in each container is read from the service state storage area; the current running state indicating that the service in the current container is to be restarted is written into the service state storage area by the service development end.

3. The containerized service restart method according to claim 1 or 2, characterized in that: If the current running state indicates that the service in the current container is to be restarted, sending a deregistration request to the service registration center includes: When the current running state is a first restart state, sending the deregistration request to the service registration center; the first restart state indicates that the service in the current container is to be restarted and access to the service in the current container is suspended; The stopping the service process in the current container includes: When the current running state is updated from the first restart state to the second restart state, the service process in the current container is stopped; and the second restart state indicates that the service in the current container enters the restart state.

4. The containerized service restart method according to any one of claims 1 to 3, characterized in that: The restarting the service process in the current container based on the acquired service update data includes: Acquire the service update data published by the service development end from the service data storage area based on the service image startup file; The service process is restarted in the current container based on the service update data.

5. The containerized service restart method according to claim 1, characterized in that: Before obtaining the current running status of the service in each container in the multiple containers, the method further includes: In response to a service restart message sent by the service development end, the current running state of the service in each container is dynamically updated; the service restart message indicates that the services in the multiple containers are restarted in batches.

6. A containerized service restart method, characterized in that: Applied to the service development end, the method includes: When it is determined that the service restart state has been entered, multiple containers of the deployed service are batched to obtain restart batch information; the multiple containers correspond to multiple service instances of the service; According to the restart batch information, the current running state of the service in each container is dynamically updated to a restart state; the restart state is used to instruct the container management end to perform a restart operation on the service process in the current container.

7. The containerized service restart method according to claim 6, characterized in that: The dynamically updating the current running state of the service in each container to a restart state according to the restart batch information includes: Determine the container to be restarted currently from the restart batch information; Setting the current running state of the service in the container to be restarted to a first restart state; the first restart state instructs the container management end to suspend receiving service requests for the container to be restarted; When it is confirmed from the service registration center that the current container to be restarted has suspended receiving service requests, the current running state of the service in the current container to be restarted is updated from the first restart state to the second restart state; the second restart state instructs the container management end to stop the service process in the current container to be restarted.

8. The containerized service restart method according to claim 7, characterized in that: The determining the current container to be restarted from the restart batch information includes: When it is confirmed from the service registration center that the service in the current batch of containers to be restarted is successfully restarted, determining the next batch of containers to be restarted from the restart batch information; The containers of the next batch to be restarted are used as the current containers to be restarted.

9. A containerized service restart device, characterized in that: Applied to a container management end, the device comprises: An acquisition module, used to acquire the current running status of a service in each of a plurality of containers; the plurality of containers correspond to a plurality of service instances of the same service; A sending module, configured to send a deregistration request to a service registration center for each container if the current running state indicates that the service in the current container is to be restarted; the deregistration request is used to instruct the service registration center to stop sending service requests to the current container; A stop module, used to stop the service process in the current container; A startup module, used to restart the service process in the current container based on the acquired service update data; The sending module is further configured to send a registration request to the service registration center when detecting that the service in the current container is successfully restarted; the registration request is used to instruct the service registration center that the current container provides services externally again.

10. A containerized service restart device, characterized in that: Applied to the service development end, the device includes: A batch module, for batching multiple containers of the deployed service to obtain restart batch information when it is determined that the service restart state has been entered; the multiple containers correspond to multiple service instances of the service; An update module is used to dynamically update the current running state of the service in each container to a restart state according to the restart batch information; the restart state is used to instruct the container management end to perform a restart operation on the service process in the current container.

11. An electronic device, characterized in that: It comprises a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement the containerized service restart method according to any one of claims 1 to 8.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement the containerized service restart method according to any one of claims 1 to 8.

13. A computer program, characterized in that When the computer program is executed by a processor, the containerized service restart method according to any one of claims 1 to 8 is implemented.

Images