CN117389648A

CN117389648A - Shutdown processing method and device, computer equipment and storage medium

Info

Publication number: CN117389648A
Application number: CN202311314370.8A
Authority: CN
Inventors: 白京陇
Original assignee: Ping An Health Insurance Company of China Ltd
Current assignee: Ping An Health Insurance Company of China Ltd
Priority date: 2023-10-10
Filing date: 2023-10-10
Publication date: 2024-01-12

Abstract

The application belongs to the technical field of data processing, and relates to a shutdown processing method, a shutdown processing device, computer equipment and a storage medium. The shutdown processing method comprises the steps of configuring a PreStop script in a configuration file of a computing cluster, executing corresponding offline processing operation in the PreStop script when the computing cluster receives a request for entering a service stop signal, acquiring processing time corresponding to the offline processing operation, and if the processing time is less than or equal to a shutdown grace time, performing normal graceful shutdown by the computing cluster. When receiving a request to enter a service stop signal, the method executes all off-line processing operations of graceful shutdown corresponding to the PreStop script, including a plurality of off-line actions such as traffic off-line, message queue SDK off-line, distributed task SDK off-line, traffic baffle establishment, container termination and the like, so that the problem of traffic loss of micro-services of an application program caused by unreasonable configuration can be prevented.

Description

Shutdown processing method and device, computer equipment and storage medium

Technical Field

The present disclosure relates to the field of data processing technologies, and in particular, to a shutdown processing method, a shutdown processing device, a computer device, and a storage medium.

Background

Users and administrators of Kubernetes cloud native clusters typically consider that a container group (pod) can always follow existing container group lifecycle rules. However, in the existing Kubernetes cloud native cluster, when a node is actively shut down (not including passive forced shutdown, power-off, etc.), the container group on the node does not follow the lifecycle flow of the container group to perform a termination operation, and cannot be stopped gracefully, so that a problem of traffic loss occurs in micro services of some applications (such as financial services, medical services, etc.).

Disclosure of Invention

The embodiment of the application aims to provide a shutdown processing method, a shutdown processing device, computer equipment and a storage medium, and solve the problem that flow loss occurs when nodes of a Kubernetes cloud primary cluster are actively shutdown.

In order to solve the above technical problems, the embodiment of the present application provides a shutdown processing method, which adopts the following technical scheme:

configuring a PreStop script in a configuration file of a computing cluster;

when the computing cluster receives a request for entering a service stop signal, executing corresponding offline processing operation in the PreStop script, and acquiring processing time corresponding to the offline processing operation;

and if the processing time is less than or equal to the shutdown grace time, the computing cluster performs normal graceful shutdown.

Further, the step of receiving the request for entering the service stop signal by the computing cluster includes:

in the starting stage of the computing cluster, acquiring an Endpoint object stored in a distributed database of the computing cluster, wherein the Endpoint object is a set of all Pod containers in the computing cluster;

when any one of the Pod containers in the Endpoint object meets an elegant shutdown condition, the computing cluster receives a request to enter a service stop signal, wherein the elegant shutdown condition is that the Pod container shifts, updates or deletes.

Further, the step of executing the corresponding offline processing operation in the PreStop script includes:

acquiring a current Pod container meeting an elegant shutdown condition in the Endpoint object;

downloading the micro-service examples corresponding to the current Pod from a registry of the computing cluster;

broadcasting the offline event of the current Pod container to other Pod containers of the Endpoint object, so that micro-service examples corresponding to the other Pod containers automatically clean a local cache.

Further, after the step of broadcasting the offline event of the current Pod to other Pod containers of the Endpoint object to enable the micro-service examples corresponding to the other Pod containers to automatically clean the local cache, the method further includes;

acquiring a current message client and a current timing task client corresponding to the current Pod container;

and setting the current message client and the current timing task client to be in a offline state according to the offline event.

Further, after the step of placing both the current message client and the current timing task client in the offline state according to the offline event, the method further includes:

establishing a flow baffle;

counting the stock flow requests in the current Pod container when the flow baffle is effective;

and if the quantity of the stock flow requests is equal to zero, confirming that the flow requests in the current Pod container are processed.

Further, after the step of completing the processing of the flow request in the current Pod container, the method further includes:

and entering into shutdown logic of the computing cluster, destroying the current Pod container, and executing the step of normal graceful shutdown of the computing cluster.

Further, after the step of performing normal graceful shutdown on the computing cluster, the method further includes:

acquiring a first computing cluster mirror image component before graceful shutdown of the computing cluster and a second computing cluster mirror image component after graceful shutdown of the computing cluster;

and rolling and upgrading the first computing cluster mirror assembly by utilizing the second computing cluster mirror assembly to obtain a new computing cluster, wherein the interface server assembly in the first computing cluster mirror assembly is reserved under the condition that the interface server assembly in the new computing cluster is upgraded from the first computing cluster mirror assembly to the second computing cluster mirror assembly.

To solve the above technical problem, the embodiments of the present application further provide a computer device, where the computer device includes a memory and a processor, where the memory stores computer readable instructions, and the processor executes the computer readable instructions to implement the steps of the shutdown processing method as described above.

To solve the above technical problem, embodiments of the present application further provide a computer readable storage medium, where computer readable instructions are stored on the computer readable storage medium, where the computer readable instructions implement the steps of the shutdown processing method described above when executed by a processor.

Compared with the prior art, the embodiment of the application has the following main beneficial effects:

according to the technical scheme provided by the application, the Prestop script is configured in the configuration file of the computing cluster, when the computing cluster receives a request for entering a service stop signal, the corresponding offline processing operation in the Prestop script is executed, the processing time corresponding to the offline processing operation is obtained, and if the processing time is less than or equal to the shutdown grace time, the computing cluster performs normal graceful shutdown. When receiving a request to enter a service stop signal, the method executes all off-line processing operations of graceful shutdown corresponding to the PreStop script, including a plurality of off-line actions such as traffic off-line, message queue SDK off-line, distributed task SDK off-line, traffic baffle establishment, container termination and the like, so that the problem of traffic loss of micro-services of an application program caused by unreasonable configuration can be prevented.

Drawings

For a clearer description of the solution in the present application, a brief description will be given below of the drawings that are needed in the description of the embodiments of the present application, it being obvious that the drawings in the following description are some embodiments of the present application, and that other drawings may be obtained from these drawings without inventive effort for a person of ordinary skill in the art.

FIG. 1 is an exemplary system architecture diagram in which the present application may be applied;

FIG. 2 is a flow chart of one embodiment of a shutdown processing method according to the present application;

FIG. 3 is a schematic view of the structure of one embodiment of a shutdown processing device according to the present application;

FIG. 4 is a schematic structural diagram of one embodiment of a computer device according to the present application.

Detailed Description

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used in the description of the applications herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having" and any variations thereof in the description and claims of the present application and in the description of the figures above are intended to cover non-exclusive inclusions. The terms first, second and the like in the description and in the claims or in the above-described figures, are used for distinguishing between different objects and not necessarily for describing a sequential or chronological order.

Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present application. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of skill in the art will explicitly and implicitly appreciate that the embodiments described herein may be combined with other embodiments.

In order to better understand the technical solutions of the present application, the following description will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the accompanying drawings.

As shown in fig. 1, a system architecture 100 may include terminal devices 101, 102, 103, a network 104, and a server 105. The network 104 is used as a medium to provide communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

The user may interact with the server 105 via the network 104 using the terminal devices 101, 102, 103 to receive or send messages or the like. Various communication client applications, such as a web browser application, a shopping class application, a search class application, an instant messaging tool, a mailbox client, social platform software, etc., may be installed on the terminal devices 101, 102, 103.

The terminal devices 101, 102, 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smartphones, tablet computers, electronic book readers, MP3 players (Moving Picture Eperts Group Audio Layer III, dynamic video expert compression standard audio plane 3), MP4 (Moving Picture Eperts Group Audio Layer IV, dynamic video expert compression standard audio plane 4) players, laptop and desktop computers, and the like.

The server 105 may be a server providing various services, such as a background server providing support for pages displayed on the terminal devices 101, 102, 103.

It should be noted that, the shutdown processing method provided in the embodiments of the present application is generally executed by a server, and accordingly, the shutdown processing device is generally disposed in the server.

It should be understood that the number of terminal devices, networks and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

With continued reference to FIG. 2, a flow chart of one embodiment of a shutdown processing method according to the present application is shown. The shutdown processing method comprises the following steps:

step S201, a PreStop script is configured in a configuration file of the computing cluster.

In this embodiment, the electronic device (for example, the terminal device shown in fig. 1) on which the shutdown processing method operates may be connected by a wired connection manner or a wireless connection manner. It should be noted that the wireless connection may include, but is not limited to, 3G/4G/5G connection, wiFi connection, bluetooth connection, wiMAX connection, zigbee connection, UWB (ultra wideband) connection, and other now known or later developed wireless connection.

In this step, the computing cluster refers to a Kubernetes cloud native cluster installed by the terminal device. The following Kubernetes cloud native clusters are presented:

for a container operation platform which is an open source, the functions of deploying, scheduling, expanding among node clusters and the like of a container can be realized by the Kubernetes, and a physical machine node or a virtual machine configured with the Kubernetes environment is called as a Kubernetes node. The Kubernetes cloud native cluster is generally formed by a plurality of Kubernetes nodes, and can realize the deployment and management of containers.

Within a Kubernetes cluster there is and only one set of control units, namely Kubernetes Master Node (Master), mainly responsible for scheduling and managing Kubernetes services, such as assigning a certain container of a certain service to a certain slave Node (Node). The Kubernetes Master node contains four subcomponents, respectively a database (etcd) component, an interface service (API Server) component, a scheduling (scheduler) component, and a control (Controller Manager) component.

In addition to Master nodes, which are cluster management nodes, the Kubernetes cluster also includes a plurality of Kubernetes slave nodes (nodes) for actually running containers assigned by the Master nodes. Wherein each node starts a Kubelet process to process tasks issued by the Master node to the node, and manages the Pod and containers therein. The Kubelet registers node information on the API Server, periodically reports node resource usage to the master, and monitors the container and node resources through the CAdvisor.

There are a number of resource types in Kubernetes, such as: pod, service, event, etc. Pod is the smallest unit in Kubernetes that can be created and deployed, and is an application instance in a Kubernetes cluster, which is always deployed on the same node. The Pod contains one or more containers and also contains resources shared by various containers such as storage, network and the like. Pod supports a variety of container environments, with dock being the most popular. Single container Pod is the most common application, while multi-container Pod is a relatively high-order use, mainly in cases where application coupling is particularly severe. Furthermore, pod is life-cycled, which can be created and terminated, but cannot be revived. The pod was created and deleted dynamically in Kubernetes by Replication Controllers. Each Pod then has its own IP address, but these IP addresses change over time. Containers within a Pod share IP addresses and port ranges, and containers may access each other through Localhost. Service is an abstract concept that defines the logical collection of Pod and policies to access these Pod. Service selects Pod by Label Selector. For example, a Pod with 3 copies running on the back end that are interchangeable, the front end need not pay attention to using that copy, or Service is the ability to achieve this decoupling. For applications local to Kubernetes, kubernetes are updated through the Endpoints API class when Pod changes in Service. For non-native applications, kubernetes provides a virtual-IP-based bridge through which the Pod of the backend is redirected. Events are used to expose situations that occur within a cluster. Various components in the Kubernetes system report various events that occur at runtime (e.g., what the scheduler makes, why certain Pod is evicted from the node) to the API Server, which stores the events in the etcd database, recording various large events encountered by the cluster running.

In specific implementation, a PreStop script is configured in a configuration file of the Kubernetes cloud native cluster. Here, the PreStop script is a script executed before the Pod container is terminated, which allows the Pod container to perform necessary cleaning operations before closing, such as: save state, disconnect from external services, etc. The function of the PreStop script is to ensure that the Pod container is normally terminated and to process all the offline operations corresponding to the PreStop script.

Step S202, when the computing cluster receives the request to enter the service stop signal, executing the corresponding offline processing operation in the PreStop script, and obtaining the processing time corresponding to the offline processing operation.

In this step, when the computing cluster receives a request to enter a service stop signal, a corresponding offline processing operation in the PreStop script is executed, and a processing time corresponding to the offline processing operation is obtained. Specifically, the step that the computing cluster receives the request to enter the service stop signal includes:

In the implementation, in the starting stage of the Kubernetes cloud native cluster, the terminal equipment acquires an Endpoint object stored in a distributed database (that is, an etcd database) of the Kubernetes cloud native cluster, wherein the Endpoint object is a set of all Pod containers in the Kubernetes cloud native cluster. Here, as can be seen from the description of step 201 above, each Pod container corresponds to an IP address and a port, and the Kubernetes cloud native cluster connects the IP address and the port corresponding to each Pod container together through a Readiness probe therein, for example: the Pod container corresponds to an IP address of 10.0.0.1 and the port of 1000, then the IP address and port connected together can be represented as (10.0.0.1:1000), and this (10.0.0.1:1000) is an Endpoint, and the endpoints are all stored in Endpoint objects in the distributed database, that is, the Endpoint objects are an Endpoint set, that is, a set of all Pod containers.

It should be noted that the Endpoint objects are real objects in the Kubernetes cloud native cluster, and for each Service, the Kubernetes cloud native cluster automatically creates one Endpoint object. An Endpoint object will store the IP addresses and ports of all Pod containers, and not only once, for example, when a Pod is created, a Pod is deleted, or a label is modified on a Pod container, the Endpoint object will update the list of endpoints.

In this step, when any one Pod container in the Endpoint object satisfies a graceful shutdown condition, the Kubernetes Yun Yuansheng cluster receives a request to enter a service stop signal, where the graceful shutdown condition is that the Pod container has drift, update, delete, or an application program in the Kubernetes cloud native cluster (such as a financial service application program, a medical service application program, etc.) needs to be published, etc. Therefore, when any one Pod container in the Endpoint object meets the graceful shutdown condition, the graceful shutdown flow is triggered, that is, the corresponding offline processing operation in the PreStop script is executed. Thus, all off-line processing operations of graceful shutdown can be completed through a single trigger point (namely, any Endpoint in the Endpoint object is used as the trigger point), including a plurality of off-line actions such as traffic off-line, message queue SDK off-line, distributed task SDK off-line, traffic baffle establishment, container termination and the like, namely, a user can complete all logic of an off-line declaration period without configuring any other trigger point, so that the problem of complicated configuration caused by dispersing to a plurality of periods can be prevented, and the problem of flow loss caused by unreasonable configuration of micro-services of an application program can be prevented.

In this step, the processing time corresponding to the offline processing operation needs to be acquired while the offline processing operation corresponding to the PreStop script is executed. Here, the processing time is a time required for completing a plurality of offline actions such as traffic offline, message queue SDK offline, distributed task SDK offline, traffic barrier establishment, container termination, and the like.

In a specific implementation, the step of executing the corresponding offline processing operation in the PreStop script includes:

Specifically, first, the current Pod container meeting the graceful shutdown condition in the Endpoint object is obtained, that is, the Endpoint meeting the graceful shutdown condition in the Endpoint object is obtained, so that the current Pod container corresponding to the IP address and the port in the Endpoint can be obtained. And then, downloading the micro-service examples corresponding to the current Pod from the registry of the computing cluster to prevent new flow from entering the micro-service examples corresponding to the current Pod. Finally, broadcasting the offline event of the current Pod to other Pod containers of the Endpoint object, so that micro-service examples corresponding to other Pod containers automatically clear the local cache, thereby preventing residual traffic from entering the micro-service examples corresponding to the current Pod container due to the local cache, where when the micro-service examples corresponding to the current Pod container are offline, the Agent reports the offline time of the micro-service examples corresponding to the current Pod container to the Agent, and after receiving the offline time, the Agent broadcasts the offline time to other micro-service examples except for the current Pod container, and after receiving the notification of the offline time, the other micro-service examples check whether the local cache contains the offline example and immediately clear.

Further, after the step of broadcasting the offline event of the current Pod to other Pod containers of the Endpoint object to enable micro-service examples corresponding to the other Pod containers to automatically clean the local cache, the method further includes;

Specifically, the terminal device obtains the current message client and the current timing task client corresponding to the current Pod container, and sends the offline operation to place the current message client and the current timing task client in an offline state, so that the current message client and the current timing task client can not receive new messages or tasks any more, and the problems of flow loss and abnormal termination of financial or medical services in the offline process of the message queue and the timing task can be prevented.

establishing a flow baffle;

Specifically, the flow baffle exists in a Filter mode, so that the aim is to prevent a new flow request from entering, namely, the new flow request is refused after the flow baffle is established, if the new flow request enters, error reporting processing is carried out, and the problem that incomplete and inconsistent financial or medical service data are caused by abnormal interruption of a continuously entering flow is prevented. After the flow baffle is effective, counting the storage flow request in the current Pod, and when the storage flow request in the current Pod is 0, considering that the storage flow request in the current Pod is processed. Therefore, the service stop can be more effective and convenient in a counting mode rather than a waiting mode of estimated time, namely the problem that the configuration waiting time is difficult to estimate is solved in a multithread counting mode, the estimated time is not needed, the actual cleaning of the number of the backlog threads at the time is taken as the standard, the automatic end is realized after the processing is finished, the problem that the plate-making efficiency is low due to the fact that the estimated time is too long is avoided, and the problem that the service interruption occurs due to the fact that the estimated time is too short is avoided.

If the number of the stock flow requests is greater than zero, continuing to execute the corresponding offline processing operation in the PreStop script until the number of the stock flow requests is equal to zero.

Further, after the flow request in the current Pod container is processed, the method further comprises stopping logic entering the computing cluster, destroying the current Pod container, and returning to execute the computing cluster to perform normal graceful stopping.

And 203, if the processing time is less than or equal to the shutdown grace time, performing normal graceful shutdown on the computing cluster.

In the step, if the processing time is less than or equal to the shutdown grace time, the Kubernetes cloud native cluster is subjected to normal and graceful shutdown. Here, the shutdown grace time is a maximum shutdown grace time defaulted by the Kubernetes cloud primary cluster, and in this embodiment, the maximum shutdown grace time is 30s, so that the terminal device can complete all offline processing operations within the maximum shutdown grace time, thereby ensuring that the problem of flow loss does not occur in the micro service of the application program.

It should be noted that there is no ongoing request in the application (e.g., financial service application, medical service application, etc.), in which case the application will be turned off directly without waiting for the end of the downtime grace period. However, if there is a request in the application (e.g., financial business application, medical business application, etc.) that is being processed, the application will wait for the downtime grace period to end before closing.

In addition, if the processing time is greater than the shutdown grace time, the computing cluster may prompt an exception and continue to force shutdown. For example, an application (e.g., a financial services application, a medical services application, etc.) may still have a pending request after a grace period of downtime, and the application may throw an exception and continue to force a shutdown.

Based on the foregoing embodiments, in some optional implementations of the present embodiment, after the step of performing a normal graceful shutdown by the computing cluster, the method further includes:

and rolling and upgrading the first computing cluster mirror assembly by utilizing the second computing cluster mirror assembly to obtain a new computing cluster, wherein the interface server assembly in the second computing cluster mirror assembly is reserved under the condition that the interface server assembly in the new computing cluster is upgraded from the first computing cluster mirror assembly to the second computing cluster mirror assembly.

In particular, an interface server component in a Kubernetes cloud native cluster before graceful shutdown is used to provide a scheduling service to a Kubernetes cloud native cluster workload resource model before graceful shutdown.

In the embodiment, the rolling upgrade is a smooth upgrade mode, component upgrade is realized by adopting a gradual replacement strategy for the Kubernetes cloud primary cluster, the stability of the whole system is ensured, and the problems can be timely found and solved when the upgrade is initialized.

In the embodiment, by rolling and upgrading the components in the Kubernetes cloud native cluster, the rolling and upgrading can avoid the integral shutdown of the Kubernetes cloud native cluster, and other components except the cluster components upgraded at the time can provide services to the outside. In this case, the interface server component in the first computing cluster mirror image component is reserved under the condition that the interface server component is upgraded, so that the external service can be continuously provided by the interface server component in the Kubernetes cloud native cluster before graceful shutdown for the Kubernetes cloud native cluster workload before graceful shutdown, which cannot adapt to the interface server component in the Kubernetes cloud native cluster before graceful shutdown, and the problem that the Kubernetes cloud native cluster cannot provide service to the external or provide service interruption to the external is solved.

In this embodiment, the second computing cluster mirror assembly is utilized, and the first computing cluster mirror assembly is rolled and upgraded in a containerized manner, so that a new computing cluster is obtained, rolling and upgrading in a containerized manner can be realized, deployment in a containerized manner is adopted, resource loss can be reduced, and expandability is stronger.

Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by computer readable instructions stored in a computer readable storage medium that, when executed, may comprise the steps of the embodiments of the methods described above. The storage medium may be a nonvolatile storage medium such as a magnetic disk, an optical disk, a Read-Only Memory (ROM), or a random access Memory (Random Access Memory, RAM).

It should be understood that, although the steps in the flowcharts of the figures are shown in order as indicated by the arrows, these steps are not necessarily performed in order as indicated by the arrows. The steps are not strictly limited in order and may be performed in other orders, unless explicitly stated herein. Moreover, at least some of the steps in the flowcharts of the figures may include a plurality of sub-steps or stages that are not necessarily performed at the same time, but may be performed at different times, the order of their execution not necessarily being sequential, but may be performed in turn or alternately with other steps or at least a portion of the other steps or stages.

With further reference to fig. 3, as an implementation of the method shown in fig. 2, the present application provides an embodiment of a shutdown processing apparatus, where the embodiment of the apparatus corresponds to the embodiment of the method shown in fig. 2, and the apparatus is particularly applicable to various electronic devices.

As shown in fig. 3, the shutdown processing apparatus 300 according to the present embodiment includes: a configuration module 301, an execution module 302, and a shutdown module 303, wherein:

a configuration module 301, configured to configure a PreStop script in a configuration file of a computing cluster;

an execution module 302, configured to execute a corresponding offline processing operation in the PreStop script when the computing cluster receives a request to enter a service stop signal, and obtain a processing time corresponding to the offline processing operation;

and the shutdown module 303 is configured to perform a normal grace shutdown on the computing cluster if the processing time is less than or equal to the shutdown grace time.

According to the technical scheme provided by the application, the Prestop script is configured in the configuration file of the computing cluster through the configuration module 301, when the computing cluster receives a request for entering a service stop signal, the execution module 302 executes corresponding offline processing operation in the Prestop script, and acquires the processing time corresponding to the offline processing operation, and if the processing time is less than or equal to the shutdown grace time, the computing cluster performs normal graceful shutdown through the shutdown module 303. When receiving a request to enter a service stop signal, the method executes all off-line processing operations of graceful shutdown corresponding to the PreStop script, including a plurality of off-line actions such as traffic off-line, message queue SDK off-line, distributed task SDK off-line, traffic baffle establishment, container termination and the like, so that the problem of traffic loss of micro-services of an application program caused by unreasonable configuration can be prevented.

In order to solve the technical problems, the embodiment of the application also provides computer equipment. Referring specifically to fig. 4, fig. 4 is a basic structural block diagram of a computer device according to the present embodiment.

The computer device 4 comprises a memory 41, a processor 42, a network interface 43 communicatively connected to each other via a system bus. It should be noted that only computer device 4 having components 41-43 is shown in the figures, but it should be understood that not all of the illustrated components are required to be implemented and that more or fewer components may be implemented instead. It will be appreciated by those skilled in the art that the computer device herein is a device capable of automatically performing numerical calculations and/or information processing in accordance with predetermined or stored instructions, the hardware of which includes, but is not limited to, microprocessors, application specific integrated circuits (Application Specific Integrated Circuit, ASICs), programmable gate arrays (fields-Programmable Gate Array, FPGAs), digital processors (Digital Signal Processor, DSPs), embedded devices, etc.

The computer equipment can be a desktop computer, a notebook computer, a palm computer, a cloud server and other computing equipment. The computer equipment can perform man-machine interaction with a user through a keyboard, a mouse, a remote controller, a touch pad or voice control equipment and the like.

The memory 41 includes at least one type of readable storage medium including flash memory, hard disk, multimedia card, card memory (e.g., SD or DX memory, etc.), random Access Memory (RAM), static Random Access Memory (SRAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), programmable Read Only Memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the storage 41 may be an internal storage unit of the computer device 4, such as a hard disk or a memory of the computer device 4. In other embodiments, the memory 41 may also be an external storage device of the computer device 4, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash Card (Flash Card) or the like, which are provided on the computer device 4. Of course, the memory 41 may also comprise both an internal memory unit of the computer device 4 and an external memory device. In this embodiment, the memory 41 is typically used to store an operating system and various types of application software installed on the computer device 4, such as computer readable instructions for shutdown processing methods. Further, the memory 41 may be used to temporarily store various types of data that have been output or are to be output.

The processor 42 may be a central processing unit (Central Processing Unit, CPU), controller, microcontroller, microprocessor, or other data processing chip in some embodiments. The processor 42 is typically used to control the overall operation of the computer device 4. In this embodiment, the processor 42 is configured to execute computer readable instructions stored in the memory 41 or process data, such as computer readable instructions for executing the shutdown processing method.

The network interface 43 may comprise a wireless network interface or a wired network interface, which network interface 43 is typically used for establishing a communication connection between the computer device 4 and other electronic devices.

The computer apparatus provided in the present embodiment can execute the shutdown processing method described above. The shutdown processing method here may be the shutdown processing method of each of the above embodiments.

The present application also provides another embodiment, namely, a computer-readable storage medium storing computer-readable instructions executable by at least one processor to cause the at least one processor to perform the steps of the shutdown processing method as described above.

From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk), comprising several instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the method described in the embodiments of the present application.

It is apparent that the embodiments described above are only some embodiments of the present application, but not all embodiments, the preferred embodiments of the present application are given in the drawings, but not limiting the patent scope of the present application. This application may be embodied in many different forms, but rather, embodiments are provided in order to provide a more thorough understanding of the present disclosure. Although the present application has been described in detail with reference to the foregoing embodiments, it will be apparent to those skilled in the art that modifications may be made to the embodiments described in the foregoing, or equivalents may be substituted for elements thereof. All equivalent structures made by the specification and the drawings of the application are directly or indirectly applied to other related technical fields, and are also within the protection scope of the application.

Claims

1. A shutdown processing method, comprising the steps of:

configuring a PreStop script in a configuration file of a computing cluster;

2. The shutdown processing method according to claim 1, wherein the step of the computing cluster receiving the request to enter service stop signal comprises:

3. The shutdown processing method according to claim 2, wherein the step of executing the corresponding offline processing operation in the PreStop script includes:

4. The shutdown processing method of claim 3, further comprising, after the step of broadcasting the offline event of the current Pod to other Pod containers of the Endpoint object to cause micro-service instances corresponding to the other Pod containers to automatically clean up a local cache;

5. The shutdown processing method of claim 3, further comprising, after the step of placing both the current messaging client and the current timed task client in a down state based on the down event:

establishing a flow baffle;

6. The shutdown processing method of claim 5, further comprising, after the step of completing the processing of the flow request in the current Pod:

7. The shutdown processing method according to any one of claims 1 to 6, further comprising, after the step of performing a normal graceful shutdown of the computing cluster:

8. A shutdown processing apparatus, comprising:

the configuration module is used for configuring the PreStop script in the configuration file of the computing cluster;

the execution module is used for executing the corresponding offline processing operation in the PreStop script and acquiring the processing time corresponding to the offline processing operation when the computing cluster receives the request for entering the service stop signal;

and the shutdown module is used for carrying out normal and graceful shutdown on the computing cluster if the processing time is less than or equal to the shutdown grace time.

9. A computer device comprising a memory having stored therein computer readable instructions which when executed by a processor implement the steps of the shutdown processing method of any of claims 1 to 7.

10. A computer readable storage medium having stored thereon computer readable instructions which when executed by a processor perform the steps of the shutdown processing method of any of claims 1 to 7.