Method and device for elegantly closing Pod based on Kubernetes, storage medium and program product

Abstract

The embodiment of the invention discloses a method and device for elegantly closing Pod based on Kubernetes, a storage medium and a program product. The method comprises the following steps: creating a termination signal of a controller for monitoring Pod in real time; when the termination signal is monitored, detecting whether Pod needs to be closed gracefully or not; if so, removing the application server running in the Pod from an available server list of the management equipment; and monitoring a request state currently processed by the application server, and deleting the Pod after all requests are completed. According to the method, the service reliability and the user experience can be effectively improved in the Kubernetes environment by automatically and elegantly closing the process.

Description

Technical Field

[0001] The present disclosure relates to the field of distributed management technology, and in particular to a method, device, storage medium, and program product for gracefully shutting down a Pod based on Kubernetes. Background Art

[0002] With the rapid development of cloud computing technology, Kubernetes has become a mainstream platform for container orchestration and management. In a Kubernetes cluster, Pod is the basic deployment unit, and its lifecycle management is crucial to ensuring the stability and reliability of services. However, existing Pod shutdown methods often lack an elegant shutdown mechanism, leading to problems such as service interruption and resource leakage. Summary of the invention

[0003] In view of this, the embodiments of the present disclosure provide a method, device, storage medium, and program product for gracefully shutting down Pods based on Kubernetes, which can effectively improve service reliability and user experience in a Kubernetes environment through an automated graceful shutdown process.

[0004] In a first aspect, the embodiments of the present disclosure provide a method for gracefully shutting down a Pod based on Kubernetes, using the following technical solution:

[0005] Create a controller to monitor the Pod's termination signal in real time;

[0006] When the termination signal is detected, detect whether the Pod needs to be shut down gracefully;

[0007] If necessary, remove the application server running in the Pod from the list of available servers on the management device;

[0008] Monitor the status of requests currently being processed by the application server and delete the Pod after all requests are completed.

[0009] Optionally, creating a controller includes:

[0010] Create Kubernetes configuration files and main program files;

[0011] Set up the controller structure;

[0012] Run the Run method in the structure to start the Pod event monitoring function and the Pod event processing function;

[0013] Load the Kubernetes configuration file in the main program file to establish communication between the controller and the Kubernetes API server;

[0014] Deploy the controller to a Kubernetes cluster;

[0015] Test the deployed controllers and start the controllers that pass the test.

[0016] Optionally, the detecting whether the Pod needs to be shut down gracefully includes:

[0017] Get the metadata of the Pod;

[0018] Detecting whether the metadata contains a graceful close flag;

[0019] If included, it means that the Pod needs to be shut down gracefully;

[0020] If not, troubleshoot the Pod.

[0021] Optionally, the troubleshooting of the Pod includes:

[0022] Check whether the Pod's container is running correctly;

[0023] If it does not run correctly, restart the container;

[0024] Determine whether the Pod has reached the resource limit conditions;

[0025] If reached, the used resources of the Pod are recorded, and the allocated resources of the Pod are adjusted based on the used resources;

[0026] Check whether the nodes of the Kubernetes cluster are healthy;

[0027] If it is unhealthy, the unhealthy node is maintained and the Pod is migrated to the healthy node during the maintenance period;

[0028] If the container runs correctly, the Pod does not reach resource constraints, and the node is healthy, the Pod data is backed up;

[0029] Force the Pod to shut down gracefully after data backup and issue an alarm.

[0030] Optionally, when it is determined that the Pod needs to be shut down gracefully, the API URL is obtained from the Pod's annotation or label through the controller;

[0031] Locate all application servers running in the Pod through the API URL and send HTTP requests;

[0032] When the application server running in the Pod receives an HTTP request through the HTTP interface, the request management device removes the application server running in the Pod from the available server list.

[0033] Optionally, removing the application server running in the Pod from the available server list of the management device includes:

[0034] Configure hook scripts or API calls in the management device;

[0035] The application server running in the Pod is removed from the available server list of the management device through the hook script or the API call.

[0036] Optionally, monitor the status of requests currently being processed by the application server in real time;

[0037] When a new request is added to the application server and needs to be processed, a counter is increased;

[0038] When the application server completes processing a request, a counter is reduced by one;

[0039] The total number of timing detection counters;

[0040] If the total number is 0, it means that all requests to the application server are completed, and a confirmation message is sent to the controller to delete the Pod by calling the Kubernetes API;

[0041] If the total number is not 0, it means that the application server has not processed all requests, and the status of the requests currently processed by the application server continues to be monitored.

[0042] In a second aspect, the disclosed embodiment also provides a system for gracefully shutting down Pods based on Kubernetes, which adopts the following technical solutions:

[0043] The monitoring module is used to create a controller to monitor the termination signal of the Pod in real time;

[0044] A detection module is used to detect whether the Pod needs to be shut down gracefully when the termination signal is monitored; if necessary, the removal module is executed;

[0045] The remove module is used to remove the application server running in the Pod from the list of available servers on the management device;

[0046] The deletion module is used to monitor the status of requests currently processed by the application server and delete the Pod after all requests are completed.

[0047] In a third aspect, the embodiments of the present disclosure further provide a computer device, which adopts the following technical solution:

[0048] The computer device comprises:

[0049] at least one processor; and,

[0050] a memory communicatively connected to the at least one processor; wherein,

[0051] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute any of the above-mentioned methods for gracefully shutting down Pods based on Kubernetes.

[0052] In a fourth aspect, an embodiment of the present disclosure further provides a computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable a computer to execute any of the above-mentioned methods for gracefully shutting down Pods based on Kubernetes.

[0053] In a fifth aspect, an embodiment of the present disclosure further provides a computer program product, including a computer program / instruction, which implements the steps of any of the above methods when executed by a processor.

[0054] The method for gracefully shutting down Pod based on Kubernetes provided by the disclosed embodiment triggers the execution logic of graceful shutdown by monitoring the termination signal of Pod, and then starts to detect whether Pod needs to be shut down gracefully, so as to achieve the purpose of simplifying the graceful shutdown process. When it is determined that Pod needs to be shut down gracefully, the application server running in Pod is removed from the list of available servers, which can flexibly manage resources and effectively reduce the number of new requests entering the application server to be shut down. Moreover, after ensuring that all requests being processed are completed, the deletion operation of Pod is performed, which can significantly reduce the service interruption caused by Pod shutdown. This method is particularly important for applications that need to process long-term or important requests, so that user requests will not be forcibly interrupted during the graceful shutdown of Pod, ensuring the integrity and consistency of user operations, and improving the overall user experience. Moreover, by monitoring the request status currently processed by the application server, it is ensured that all requests are processed before Pod is shut down, effectively avoiding data loss and inconsistency caused by forced shutdown.

[0055] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the following preferred embodiments are specifically cited and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0057] Figure 1 A flow chart of a method for gracefully shutting down a Pod based on Kubernetes provided in an embodiment of the present disclosure;

[0058] Figure 2 A flowchart of a controller creation method provided in an embodiment of the present disclosure;

[0059] Figure 3 A flowchart of a troubleshooting method provided by an embodiment of the present disclosure;

[0060] Figure 4 A flowchart of an application server request management method provided by an embodiment of the present disclosure;

[0061] Figure 5 A functional block diagram of a system for gracefully shutting down Pods based on Kubernetes provided in an embodiment of the present disclosure;

[0062] Figure 6 A schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0063] The embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0064] It should be clear that the following embodiments of the present disclosure are described by specific specific examples, and those skilled in the art can easily understand other advantages and effects of the present disclosure from the contents disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. The present disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present disclosure. It should be noted that the following embodiments and features in the embodiments can be combined with each other in the absence of conflict. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present disclosure.

[0065] It should be noted that various aspects of the embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein may be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on the present disclosure, it should be understood by those skilled in the art that an aspect described herein may be implemented independently of any other aspect, and two or more of these aspects may be combined in various ways. For example, any number of aspects described herein may be used to implement the device and / or practice the method. In addition, other structures and / or functionalities other than one or more of the aspects described herein may be used to implement this device and / or practice this method.

[0066] It should also be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present disclosure. The drawings only show components related to the present disclosure rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0067] Additionally, in the following description, specific details are provided to facilitate a thorough understanding of the examples. However, it will be understood by those skilled in the art that the aspects described may be practiced without these specific details.

[0068] Reference Figure 1 The present disclosure provides a method for gracefully shutting down a Pod based on Kubernetes, comprising the following steps:

[0069] S1: Create a controller to monitor the termination signal of the Pod in real time;

[0070] S2: When a termination signal is detected, detect whether the Pod needs to be shut down gracefully;

[0071] S3: If necessary, remove the application server running in the Pod from the list of available servers on the management device;

[0072] S4: Monitors the status of requests currently being processed by the application server and deletes the Pod after all requests are completed.

[0073] Among them, Pod is the basic deployment unit in the Kubernetes cluster (i.e. K8s), which contains one or more containers (such as Docker containers). These containers share network and storage resources. Pod can be regarded as a "virtual machine" in the Kubernetes cluster, but they are lighter than virtual machines because they share the same operating system kernel. The Kubernetes cluster manages the life cycle of these Pods, including creation, scheduling, operation, expansion and deletion.

[0074] Microservice architecture is a software development architecture that builds applications as a series of small, independent, loosely coupled services that are organized around business capabilities and can be independently deployed, expanded, and updated. Each service implements specific business functions and can communicate through defined APIs that are accessed through IP addresses and ports. In a microservice architecture, services are usually lightweight and can be implemented in different programming languages ​​and data storage technologies. Services include service providers and service callers. Service providers are services that provide specific functions, while service callers are clients that use these services.

[0075] Tomcat is an open source Java Servlet container, which is regarded as an application server. Java Web applications are deployed on such an application server. The application server can run independently, but it can also be deployed in a Kubernetes environment. This disclosure chooses to deploy the application server in a Kubernetes environment so that the application server runs in the corresponding Pod.

[0076] The existing Kubernetes environment has provided mechanisms such as PreStop hooks and TerminationGracePeriodSeconds, but these mechanisms are difficult to fully meet the needs in long-term tasks or specific business scenarios, especially in scenarios where it is necessary to ensure that ongoing requests can be completed, it is difficult to achieve a true "elegant shutdown". The method of elegantly shutting down Pod based on Kubernetes in this application triggers the execution logic of elegant shutdown by listening to the termination signal of Pod, and then starts to detect whether Pod needs to be shut down gracefully, so as to simplify the elegant shutdown process. When it is determined that Pod needs to be shut down gracefully, the application server running in Pod is removed from the list of available servers, which can flexibly manage resources and effectively reduce new requests entering the application server to be shut down. Moreover, after ensuring that all requests being processed are completed, the deletion operation of Pod is performed, which can significantly reduce the service interruption caused by Pod shutdown. This method is particularly important for applications that need to process long-term or important requests, so that user requests will not be forced to be interrupted during the elegant shutdown of Pod, ensuring the integrity and consistency of user operations, and improving the overall user experience. Moreover, by monitoring the request status currently processed by the application server, it is ensured that the request is processed before the Pod is shut down, effectively avoiding data loss and inconsistency caused by forced shutdown.

[0077] In summary, by automating the graceful shutdown process, we can reduce the potential human errors and risks of operation and maintenance personnel when manually handling Pod shutdowns, ensure the consistency of system configuration, and effectively improve service reliability and user experience in the Kubernetes environment, while providing higher flexibility and credibility for operation and development.

[0078] In S1, refer to Figure 2 The flowchart of the controller creation method shown in the figure includes the following steps:

[0079] S11: Create Kubernetes configuration files and main program files;

[0080] S12: Set the controller structure;

[0081] S13: Run the Run method in the structure to start the Pod event monitoring function and the Pod event processing function;

[0082] S14: Load the Kubernetes configuration file in the main program file and establish communication between the controller and the Kubernetes API server;

[0083] S15: Deploy the controller to the Kubernetes cluster;

[0084] S16: Test the deployed controllers and start the controllers that pass the test.

[0085] In S11, ensure that the Kubernetes cluster has been deployed and is accessible, and install the Go language environment and required dependency management tools, such as go mod. Create a Go project directory in the local development environment and initialize the Go module. In the Go project directory, run go mod init <module-name>To initialize the Go module, use the go get command or add the k8s.io / client-go library as a dependency in the go.mod file to interact with the Kubernetes API (a set of defined interfaces and endpoints).

[0086] Create a Kubernetes configuration file, namely kubeconfig file, which contains the authentication information required to access the Kubernetes cluster (such as API server address, certificate, username, etc.).

[0087] Create the main program file, main.go, in the root directory of the Go project as the entry point of the controller.

[0088] In S12, in the main program file or in a newly created file (such as controller.go), define a controller structure that contains a reference to the Kubernetes client, event handling functions, loggers, etc.

[0089] In S13, a Run method is added to the structure of the controller. In the Run method, a coroutine is started to monitor Pod-related events to implement the Pod event monitoring function and the Pod event processing function. Pod events include Pod termination events, which are implemented by monitoring the termination signal of the Pod. After monitoring the Pod termination event, the corresponding processing measures will be started to implement the Pod event processing function. The specific implementation logic of the Pod event processing function is implemented by adding the HandlePodTerminated method in the structure of the controller.

[0090] In S14, a flag is set in the main program file to specify the path of the Kubernetes configuration file, and the Kubernetes configuration file is loaded and parsed to create and initialize a Kubernetes client. Combined with the reference of the Kubernetes client contained in the structure of the controller, the Kubernetes client allows the controller to interact with the Kubernetes API server to complete the communication between the two. Among them, the Kubernetes API server is one of the core components of the Kubernetes control plane. It is a process that runs on the Kubernetes master node and serves as the front-end service of the Kubernetes API. The Kubernetes client is a library for interacting with the Kubernetes API server. The Kubernetes client and the Kubernetes API server together constitute the infrastructure for Kubernetes cluster management, making cluster management simple and efficient.

[0091] In S15, create a Kubernetes Deployment YAML file and define the controller's Deployment configuration, including images, environment variables, and ports. Use kubectl apply -f <deployment-file>The .yaml command deploys the controller to the Kubernetes cluster.

[0092] In S16, make sure the controller is running and monitor its logs to confirm whether the function is normal. Under normal circumstances, create a test Pod in the Kubernetes cluster and set appropriate annotations or labels to observe the behavior of the controller when the test Pod is terminated, confirm that the controller can correctly handle events and call the graceful shutdown API. If the controller test fails, check whether there are errors in the function implementation of the controller and correct the errors; if the controller test passes, start the controller through the Run method and listen to the termination signal of the Pod in real time.

[0093] In S2, termination signals are generated by user requests, cluster autoscaling, node maintenance or upgrades, etc. Specifically, when a user deletes a Pod through kubectl delete or other Kubernetes API client tools, a termination signal is generated; when the Kubernetes cluster's autoscaler (such as the Horizontal Pod Autoscaler) reduces the number of Pods based on load conditions, a termination signal is triggered; when a node in a Kubernetes cluster needs maintenance or an upgrade, all Pods running on the node will receive a termination signal. A node refers to a working unit in a Kubernetes cluster, which is the place where a Pod runs and is responsible for maintaining the containers running on it. A node can be a virtual machine or a physical machine.

[0094] When the controller detects a termination signal, it indicates that a Pod termination event has occurred. In the HandlePodTerminated method, the metadata of the Pod to be terminated is obtained through the Kubernetes client. The metadata includes annotations or labels. Check whether the annotations or labels contain an elegant shutdown flag. If so, it means that the Pod needs to be shut down gracefully. If not, troubleshoot the Pod.

[0095] Among them, the Kubernetes API itself does not directly support all possible graceful shutdown logic. The use of annotations or labels can extend the functionality of Kubernetes, allowing developers to implement customized shutdown logic based on business needs. By setting the graceful shutdown flag in the annotation or label, the deployer can flexibly configure different shutdown strategies for different Pods or deployments without modifying the application code in the image or container. For example, if the annotation contains graceful.shutdown=true, it means that the annotation contains the graceful shutdown flag.

[0096] Reference Figure 3 The flowchart of the troubleshooting method shown in the figure shows that when the termination signal is detected but the graceful shutdown flag is not detected, the specific steps of troubleshooting include:

[0097] S21: Check whether the container of the Pod is running correctly; if not, execute S22; if yes, execute S24;

[0098] S22: Restart the container to determine whether the Pod has resumed normal operation; if not, execute S23; if yes, execute S24;

[0099] S23: Detect and record the failure reason for restarting the container, optimize the container based on the failure reason, and execute S24;

[0100] S24: Determine whether the Pod meets the resource limit condition; if so, execute S25; if not, execute S26;

[0101] S25: Record the used resources of the Pod, adjust the allocated resources of the Pod based on the used resources, and execute S26;

[0102] S26: Check whether the nodes of the Kubernetes cluster are healthy; if not, execute S27; if so, execute S28;

[0103] S27: Perform maintenance on unhealthy nodes and migrate Pods to healthy nodes during the maintenance period.

[0104] S28: Back up the Pod data, force the Pod to shut down gracefully, and issue an alarm.

[0105] In S21-S23, use the kubectl get pods command to check the status of the Pod. If the container is running, the status will be displayed as Running. Otherwise, use the kubectl describe pod command to view the Pod event to identify the Pod abnormality. When the Pod is determined to be normal or abnormal, try to restart the container. If the restart fails, optimize the container according to the failure reason.

[0106] In S24-S25, the current CPU usage and current memory usage of the Pod's resources are displayed using kubectltop pod <pod-name>The command obtains the current CPU usage and current memory usage of the Pod. If the current CPU usage reaches the CPU threshold or the current memory usage reaches the memory threshold, it means that the Pod has reached the resource limit. Use the kubectlset resources command to temporarily allocate a higher CPU usage or memory usage to the Pod. However, if the CPU allocation is greater than the upper limit or the memory allocation is greater than the upper limit, abandon the resource allocation adjustment and optimize the application code or configuration later to prevent affecting the use of other devices. If the current CPU usage does not reach the CPU threshold and the current memory usage does not reach the memory threshold, it means that the Pod has not reached the resource limit.

[0107] In S26-S27, the kubectl get nodes command is executed to view the node status information, including the node name, internal IP address, role, etc. The kubectl get nodes command will output the Ready indicator or the NotReady indicator according to the node status information. If it is the Ready indicator, it means that the node is healthy; if it is the NotReady indicator, it means that the node is unhealthy and the node is marked as unschedulable, which means using kubectl cordon <node-name>Command to prohibit new Pods from being scheduled to the node, and then use kubectl drain <node-name>Command to evict the Pod on the node to other healthy nodes. During the period when the node is unschedulable, perform maintenance measures such as system upgrades or hardware replacements. After the maintenance is completed, use kubectl uncordon <node-name>Command to restore the scheduling status of the node and migrate the expelled Pod back to the node.

[0108] In S28, by executing S21-S26, if no termination signal but no graceful shutdown mark is detected temporarily, the Pod data is backed up, and then the Pod is forced to be gracefully closed, and an alarm is issued to remind the staff to conduct in-depth investigation.

[0109] In S3, an HTTP interface (such as the / shutdown interface) is pre-built in all application servers, and the HTTP interface is deployed to the Kubernetes cluster, which can call the HTTP interface. In the Kubernetes Pod definition, the API URL of the HTTP interface is specified through annotations or labels. The API URL is the Uniform Resource Locator of the Application Programming Interface (API), which is similar to an address on the Internet and is used to refer to the specific location of the HTTP interface. Through the API URL, a corresponding relationship can be established between each Pod and the application server running in the Pod.

[0110] When it is determined that the Pod needs to be shut down gracefully, the controller obtains the API URL from the Pod's annotations or labels, and locates all application servers running in the Pod through the API URL. The controller sends an HTTP request through the API URL to trigger the graceful shutdown process. When the application server running in the Pod receives the HTTP request through the HTTP interface, it starts to perform the graceful shutdown operation.

[0111] Create a class containing the shutdown function. This class can be customized as ShutDownController. The shutdown function can not only implement the / shutdown interface, but also perform graceful shutdown operations on the application server, including stopping the running background tasks or timers in the application, persisting the current application state of the application server to the file system or database so that it can be restored later, cleaning up and releasing the resources used by the application, such as closing the network connection, releasing the lock, etc., to ensure that all resources have been properly handled and there are no remaining resources occupied, so that the application can be safely closed, while retaining the necessary information for future recovery or auditing. This is an application-level shutdown operation, which ensures that the application can be closed safely and orderly, avoiding data loss and service interruption.

[0112] The graceful shutdown operation also includes that after the application server receives the HTTP request, the application server notifies the management device to remove itself from its available server list to ensure that new requests are not sent to the application server that is about to be stopped. The management device includes at least one of the load balancer and service proxy. The load balancer and service proxy are responsible for distributing external requests to the backend service. If the Pod is about to be shut down, but the corresponding application server still appears in the available server list, new requests may be sent to this Pod, resulting in service interruption or request failure. Therefore, dynamic management of the available server list is very necessary.

[0113] If the management device includes a load balancer (such as NGINX or Ingress), pre-configure the load balancer's list of available servers as a separate dynamic configuration file, for example, create a dynamic configuration file named upstreams.conf to maintain the list of available servers. In the main configuration file of the load balancer, use the include directive to reference the dynamic configuration file so that updates to the list of available servers can be reflected in the load balancer's configuration in real time. When you need to remove the application server running in the Pod that is about to be shut down, you can do so by updating the dynamic configuration file. After the update is complete, execute the load balancer's reload command (for example, use nginx-s reload for NGINX) to make the new configuration take effect.

[0114] The principle of removing the application server running in the Pod from the service proxy's list of available servers is the same as the principle of removing the load balancer mentioned above, so I will not repeat it here.

[0115] Furthermore, a hook script or API call is added to the configuration of the management device so that the removal operation is automatically performed when an elegant shutdown request (i.e., HTTP request) is received. When the Pod needs to be shut down gracefully, the application server running in the Pod is removed from the dynamic configuration file through the hook script or API call, thereby deregistering the server from the list of available servers of the management device.

[0116] Among them, a hook script is a script that is automatically executed when a specific event occurs. In the context of a service proxy or load balancer, a hook script is configured. When a graceful shutdown signal is received, the hook script is automatically executed to update the configuration of the service proxy or load balancer, thereby removing the application server that is about to be shut down from the list of available servers. API call refers to the process of sending a request from one system to another, which is used for communication between different services or components. In this case, when the load balancer or service proxy receives a graceful shutdown request, it notifies it through an API call to update the internal state and remove the specified application server from the list of available servers.

[0117] In S4, refer to Figure 4 The flowchart of the application server request management method shown is a method for determining whether all requests of the application server are completed, including the following steps:

[0118] S41: real-time monitoring of the request status currently processed by the application server;

[0119] S42: when a new request is added to the application server and needs to be processed, a counter is increased;

[0120] S43: When the application server completes processing one request, one counter is reduced;

[0121] S44: Regularly check the total number of the counter to determine whether the total number is 0. If so, execute S45; if not, return to S41;

[0122] S45: Indicates that all requests to the application server are completed, and a confirmation message is sent to the controller. The controller calls the Kubernetes API to delete the Pod.

[0123] In S41-S45, an interceptor is created for each application server, such as RequestCounterInterceptor, to intercept requests entering the application server. Three functions, before_request, after_request and get_request, are defined in the interceptor. Through the before_request function, the counter is increased every time a new request arrives at the application server; through the after_request function, the counter is reduced every time a request is processed in the application server. Note that the initial number of the counter is 0. The total number of counters is regularly counted through the get_request function, for example, once every 500 milliseconds. If the total number is not 0, it means that the requests of the application server have not been fully processed, and it is necessary to continue to monitor the request processing progress in the application server; if the total number is 0, it means that the requests of the application server have been fully processed, and the application server sends a confirmation message to the controller.

[0124] Furthermore, in addition to the situation where the request is processed normally, some abnormal processing may occur, such as processing timeout, returning a status code that does not meet the expectations, or returning a response that does not meet the expected format or content. To this end, it is necessary to record the processing time of each request. If the processing time exceeds the preset time threshold or the request is abnormal, the request is actively closed, the request is determined to be processed, and resources are released. If the request is processed within the preset time threshold and no abnormality occurs, the request is closed normally and the request is determined to be processed.

[0125] When the controller receives confirmation messages from all application servers running in the Pod, the controller calls the Kubernetes API to delete the Pod. Specifically, the controller needs to load the configuration of the Kubernetes API, including configuring the Kubernetes API client. If the controller runs outside the Kubernetes cluster, the configuration of the Kubernetes API is loaded by reading the Kubernetes configuration file; if the controller runs inside the Kubernetes cluster, the configuration information of the Kubernetes cluster is obtained from the environment variables of the Pod by calling the config.load_incluster_config() method, so that it can communicate with the Kubernetes API securely. After the configuration is loaded, the controller needs to instantiate the Kubernetes API client. Specifically, the controller creates a CoreV1Api instance, which provides a series of methods for interacting with core Kubernetes resources (such as Pod, Service, etc.). The Kubernetes API client provides an interface for interacting with the Kubernetes cluster, including create, read, update, and delete (CRUD) operations. Therefore, the instantiation of the Kubernetes API client enables the controller to easily use these interfaces to manage various resources in Kubernetes, thereby creating, querying, and deleting Pods. Next, the controller calls the delete_namespaced_pod method (a secondary API method), passing in the Pod name, namespace, and deletion options, where name is the name of the Pod to be deleted, namespace is the namespace where the Pod is located, ensuring that the controller can accurately locate the Pod to be deleted, and the deletion options include setting a graceful shutdown time (grace_period_seconds) to ensure that the Pod has enough time to complete its ongoing tasks before being forcibly shut down. The deletion options also include setting policies to instruct the Kubernetes cluster how to handle other resources that the Pod depends on.

[0126] Exceptions may occur during the Pod deletion process. To this end, the controller captures ApiException to identify exceptions generated when deleting the Pod and handles these exceptions. For example, if the specified Pod has been deleted or never existed, it means that the resource is not found, and the Kubernetes API returns a 404 error. The controller records this status to prevent incorrect operations. For another example, if the controller does not have sufficient permissions to perform the deletion operation, the Kubernetes API returns a 403 error. The controller needs to check its access control settings, then correct the access control permissions, and delete the Pod again. For another example, if a 503 error occurs due to a network outage, the controller records the error and prepares to retry, and then deletes the Pod again.

[0127] After attempting to delete the Pod, the controller confirms whether the Pod has been successfully deleted. Although the Kubernetes cluster can automatically handle these requests, the controller can query the status of the Pod by calling the Kubernetes API to ensure that the deletion has actually occurred. This is achieved by obtaining a list of Pods under a specified namespace. If the Pod still exists, it means that the deletion request has not been processed and the Pod needs to be deleted again to ensure that the Pod is successfully deleted. If the number of deletions reaches the preset threshold and the Pod is still not successfully deleted, an alarm is issued and staff are brought in to handle it.

[0128] After the application server completes the graceful shutdown logic, the controller needs to monitor whether all currently processed requests on the application server have been completed. Once all requests have been completed, the controller will call the Kubernetes API to delete the Pod and release cluster resources. This is resource management at the Kubernetes level, ensuring that once the application is shut down, the related Kubernetes resources will also be properly cleaned up, maintaining the health and efficiency of the Kubernetes cluster.

[0129] Reference Figure 5 The present disclosure provides a system for gracefully shutting down Pods based on Kubernetes, including:

[0130] Monitoring module 101, used to create a controller to monitor the termination signal of the Pod in real time;

[0131] The detection module 102 is used to detect whether the Pod needs to be shut down gracefully when a termination signal is monitored; if necessary, the removal module 103 is executed;

[0132] A removal module 103, used to remove the application server running in the Pod from the available server list of the management device;

[0133] The deletion module 104 is used to monitor the status of the requests currently processed by the application server and delete the Pod after all requests are completed.

[0134] The various variations and specific examples of the method for gracefully shutting down Pods based on Kubernetes provided above are also applicable to the system for gracefully shutting down Pods based on Kubernetes provided in the present disclosure. Through the above detailed description of the method for gracefully shutting down Pods based on Kubernetes, those skilled in the art can clearly understand the implementation method of the system for gracefully shutting down Pods based on Kubernetes. For the sake of brevity of the specification, it will not be described in detail here.

[0135] The computer device according to the embodiment of the present disclosure includes a memory and a processor. The memory is used to store non-temporary computer-readable instructions. Specifically, the memory may include one or more computer program products, and the computer program product may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include a random access memory (RAM) and / or a cache memory (cache), etc. The non-volatile memory may, for example, include a read-only memory (ROM), a hard disk, a flash memory, etc.

[0136] The processor may be a central processing unit (CPU) or other forms of processing units having data processing capabilities and / or instruction execution capabilities, and may control other components in the computer device to perform desired functions. In one embodiment of the present disclosure, the processor is used to run the computer-readable instructions stored in the memory, so that the computer device performs all or part of the steps of the method for gracefully shutting down a Pod based on Kubernetes in the aforementioned embodiments of the present disclosure.

[0137] Those skilled in the art should be able to understand that in order to solve the technical problem of how to obtain a good user experience, the present embodiment may also include well-known structures such as a communication bus and an interface, and these well-known structures should also be included in the protection scope of the present disclosure.

[0138] like Figure 6 A schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure is shown, which is a schematic diagram of the structure of a computer device suitable for implementing the embodiment of the present disclosure. Figure 6 The computer device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0139] like Figure 6 As shown, the computer device may include a processor (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) or a program loaded from a storage device into a random access memory (RAM). In the RAM, various programs and data required for the operation of the computer device are also stored. The processor, ROM, and RAM are connected to each other via a bus. An input / output (I / O) interface is also connected to the bus.

[0140] Typically, the following devices can be connected to the I / O interface: input devices such as sensors or visual information acquisition devices; output devices such as display screens; storage devices such as tapes, hard disks, etc.; and communication devices. The communication device can allow the computer device to communicate with other devices (such as edge computing devices) wirelessly or by wire to exchange data. Figure 6 A computer device having various devices is shown, but it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed instead.

[0141] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through a communication device, or installed from a storage device, or installed from a ROM. When the computer program is executed by the processor, all or part of the steps of the method for gracefully shutting down Pods based on Kubernetes of the embodiment of the present disclosure are executed. For detailed descriptions of this embodiment, reference can be made to the corresponding descriptions in the aforementioned embodiments, which will not be repeated here.

[0142] According to the computer-readable storage medium of the embodiment of the present disclosure, non-transitory computer-readable instructions are stored thereon. When the non-transitory computer-readable instructions are executed by the processor, all or part of the steps of the method for gracefully shutting down a Pod based on Kubernetes of the aforementioned embodiments of the present disclosure are executed.

[0143] The above-mentioned computer-readable storage media include, but are not limited to: optical storage media (e.g., CD-ROM and DVD), magneto-optical storage media (e.g., MO), magnetic storage media (e.g., magnetic tape or mobile hard disk), media with built-in rewritable non-volatile memory (e.g., memory card) and media with built-in ROM (e.g., ROM box).

[0144] For detailed description of this embodiment, reference may be made to the corresponding descriptions in the aforementioned embodiments, which will not be repeated here.

[0145] The basic principles of the present disclosure are described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, effects, etc. mentioned in the present disclosure are only examples and not limitations, and it cannot be considered that these advantages, strengths, effects, etc. are required by each embodiment of the present disclosure. In addition, the specific details disclosed above are only for the purpose of illustration and ease of understanding, and are not limiting. The above details do not limit the present disclosure to the necessity of adopting the above specific details to be implemented.

[0146] In the present disclosure, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. The block diagrams of the devices, devices, equipment, and systems involved in the present disclosure are only illustrative examples and are not intended to require or imply that they must be connected, arranged, and configured in the manner shown in the block diagram. As will be recognized by those skilled in the art, these devices, devices, equipment, and systems can be connected, arranged, and configured in any manner. Words such as "including", "comprising", "having", etc. are open words, meaning "including but not limited to", and can be used interchangeably with them. The words "or" and "and" used here refer to the words "and / or" and can be used interchangeably with them, unless the context clearly indicates otherwise. The word "such as" used here refers to the phrase "such as but not limited to", and can be used interchangeably with it.

[0147] Additionally, as used herein, "or" used in a list of items beginning with "at least one" indicates a disjunctive list, so that, for example, a list of "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not mean that the example described is preferred or better than other examples.

[0148] It should also be noted that in the system and method of the present disclosure, each component or each step can be decomposed and / or recombined. Such decomposition and / or recombination should be regarded as equivalent solutions of the present disclosure.

[0149] Various changes, substitutions, and modifications of the techniques described herein may be made without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of the present disclosure is not limited to the specific aspects of the processes, machines, manufactures, compositions of events, means, methods, and actions described above. Currently existing or later to be developed processes, machines, manufactures, compositions of events, means, methods, or actions that perform substantially the same functions or achieve substantially the same results as the corresponding aspects described herein may be utilized. Thus, the appended claims include such processes, machines, manufactures, compositions of events, means, methods, or actions within their scope.

[0150] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of the present disclosure. Therefore, the present disclosure is not intended to be limited to the aspects shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

[0151] The above description has been given for the purpose of illustration and description. In addition, this description is not intended to limit the embodiments of the present disclosure to the forms disclosed herein. Although multiple example aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, changes, additions and sub-combinations thereof.

Claims

1. A method for gracefully shutting down Pod based on Kubernetes, characterized in that: include: Create a controller to monitor the Pod's termination signal in real time; When the termination signal is detected, detect whether the Pod needs to be shut down gracefully; If necessary, remove the application server running in the Pod from the list of available servers on the management device; Monitor the status of requests currently being processed by the application server and delete the Pod after all requests are completed.

2. The method for gracefully shutting down Pod based on Kubernetes according to claim 1 is characterized in that: The creation controller includes: Create Kubernetes configuration files and main program files; Set up the controller structure; Run the Run method in the structure to start the Pod event monitoring function and the Pod event processing function; Load the Kubernetes configuration file in the main program file to establish communication between the controller and the Kubernetes API server; Deploy the controller to a Kubernetes cluster; Test the deployed controllers and start the controllers that pass the test.

3. According to the method for gracefully shutting down Pod based on Kubernetes in claim 1, it is characterized in that: The detection of whether the Pod needs to be shut down gracefully includes: Get the metadata of the Pod; Detecting whether the metadata contains a graceful close flag; YY+242194P If included, it means that the Pod needs to be shut down gracefully; If not, troubleshoot the Pod.

4. The method for gracefully shutting down Pod based on Kubernetes according to claim 3 is characterized in that: The Pod troubleshooting includes: Check whether the Pod's container is running correctly; If it does not run correctly, restart the container; Determine whether the Pod has reached the resource limit conditions; If reached, the used resources of the Pod are recorded, and the allocated resources of the Pod are adjusted based on the used resources; Check whether the nodes of the Kubernetes cluster are healthy; If it is unhealthy, the unhealthy node is maintained and the Pod is migrated to the healthy node during the maintenance period; If the container runs correctly, the Pod does not reach resource constraints, and the node is healthy, the Pod data is backed up; Force the Pod to shut down gracefully after data backup and issue an alarm.

5. The method for gracefully shutting down Pod based on Kubernetes according to claim 1 is characterized in that: When it is determined that the Pod needs to be shut down gracefully, the controller obtains the API URL from the Pod's annotations or labels; Locate all application servers running in the Pod through the API URL and send HTTP requests; When the application server running in the Pod receives an HTTP request through the HTTP interface, it requests the management device to remove the application service running in the Pod from the list of available servers. device.

6. The method for gracefully shutting down Pod based on Kubernetes according to claim 5 is characterized in that: The removing the application server running in the Pod from the available server list of the management device includes: Configure hook scripts or API calls in the management device; The application server running in the Pod is removed from the available server list of the management device through the hook script or the API call.

7. The method for gracefully shutting down Pod based on Kubernetes according to claim 1 is characterized in that: Real-time monitoring of the status of requests currently being processed by the application server; When a new request is added to the application server and needs to be processed, a counter is increased; When the application server completes processing a request, a counter is reduced by one; The total number of timing detection counters; If the total number is 0, it means that all requests to the application server are completed, and a confirmation message is sent to the controller to delete the Pod by calling the Kubernetes API; If the total number is not 0, it means that the application server has not processed all requests, and the status of the requests currently processed by the application server continues to be monitored.

8. A computer device, characterized in that: The computer device comprises: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the right YY+242194P The method for gracefully shutting down a Pod based on Kubernetes as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, which are used to enable a computer to execute the method for gracefully shutting down a Pod based on Kubernetes as described in any one of claims 1-7.

10. A computer program product comprising computer instructions, characterized in that: When the computer instructions are executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images