Business process restarting method and device of container arrangement platform, computer equipment, medium and product

Abstract

The invention relates to a service process restarting method and device of a container arrangement platform, computer equipment, a medium and a product. The service process restarting method of the container arrangement platform comprises the steps of extracting restarting configuration information from a restarting operation instruction under the condition that the restarting operation instruction aiming at a target service process of a container in a current arrangement unit is detected; according to the restart configuration information, carrying out restart preprocessing on the target business process; and after the target service process completes the restart preprocessing, performing in-situ restart on the target service process. By adopting the method, the flexibility of restarting the business process of the container arrangement platform is improved.

Description

Technical Field

[0001] This application relates to the field of container orchestration technology, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for restarting business processes on a container orchestration platform. Background Technology

[0002] With the development of technology, container orchestration platforms have emerged to meet the needs of rapid business iteration and cross-environment deployment. Container orchestration platforms can realize the automated deployment, scheduling and lifecycle management of massive containers and the unified allocation of resources to ensure the consistent operation of services in different environments. However, in the process of applying container orchestration platforms, the need to restart business processes will inevitably be encountered.

[0003] Currently, restarting business processes on container orchestration platforms is typically done within the container, such as through a Liveness probe mechanism or by implementing a custom DaemonSet to rebuild the container. However, since a container contains multiple independent or related processes, restarting within the container will force a restart of all processes within the container. This can easily lead to resource waste and data consistency risks caused by the restart of unrelated processes. Therefore, the current method of restarting business processes on container orchestration platforms is not very flexible. Summary of the Invention

[0004] Based on this, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for restarting business processes of a container orchestration platform to improve the flexibility of restarting business processes of the container orchestration platform, thereby addressing the aforementioned technical problems.

[0005] Firstly, this application provides a method for restarting business processes in a container orchestration platform, the method comprising:

[0006] If a restart operation instruction is detected for the target service process of the current orchestration unit content device, restart configuration information is extracted from the restart operation instruction;

[0007] Based on the restart configuration information, perform pre-restart processing on the target business process;

[0008] After the target business process completes the pre-restart processing, the target business process is restarted in place.

[0009] In one embodiment, the step of performing pre-restart processing on the target service process based on the restart configuration information includes:

[0010] The restart operation type of the target business process is parsed from the restart configuration information;

[0011] Perform the restart pre-operation of the restart operation type on the target business process.

[0012] In one embodiment, the pre-restart operation of the restart operation type performed on the target service process includes:

[0013] When the restart operation type is a process version upgrade, the download address of the new version of the process is parsed from the restart configuration information;

[0014] Download the executable file of the new version of the process from the provided download address;

[0015] The executable file is stored in the shared storage space of the current orchestration unit.

[0016] In one embodiment, the pre-restart operation of the restart operation type performed on the target service process includes:

[0017] When the restart operation type is process restart, the configuration update field is parsed from the restart configuration information;

[0018] Based on the configuration update fields, perform a restart preprocessing for the target business process.

[0019] In one embodiment, the step of performing restart preprocessing on the target business process based on the configuration update field includes:

[0020] If configuration information to be updated is detected in the configuration update field, a configuration file is generated based on the container file update information in the configuration update field, and the configuration file is stored in the shared storage space of the current orchestration unit.

[0021] If the configuration information to be updated is not found in the configuration update field, a graceful stop operation is performed on the target business process.

[0022] In one embodiment, restarting the target service process in place includes:

[0023] If a restart file is detected in the shared storage space of the current orchestration unit, the execution directory of the target business process is pointed to the corresponding file storage path in the shared storage space, and the target business process is restarted. The restart file includes an executable file and a configuration file.

[0024] If the restart file is not found in the shared storage space, the target business process is restarted.

[0025] Secondly, this application also provides a business process restart device for a container orchestration platform, the device comprising:

[0026] The extraction module is used to extract restart configuration information from the restart operation instruction when a restart operation instruction for the target service process of the current orchestration unit content device is detected.

[0027] The pre-processing module is used to perform pre-restart processing on the target business process according to the restart configuration information;

[0028] The restart module is used to restart the target business process in place after the target business process has completed the pre-restart processing.

[0029] In one embodiment, the preprocessing module is further configured to:

[0030] The restart operation type of the target business process is parsed from the restart configuration information; the restart pre-operation of the restart operation type is performed on the target business process.

[0031] In one embodiment, the preprocessing module is further configured to:

[0032] When the restart operation type is a process version upgrade, the download address of the new version of the process is parsed from the restart configuration information; the executable file of the new version of the process is downloaded according to the download address; and the executable file is stored in the shared storage space of the current orchestration unit.

[0033] In one embodiment, the preprocessing module is further configured to:

[0034] When the restart operation type is process restart, the configuration update field is parsed from the restart configuration information; and the target business process is preprocessed for restart based on the configuration update field.

[0035] In one embodiment, the preprocessing module is further configured to:

[0036] If the configuration update field detects that there is configuration information to be updated, a configuration file is generated based on the container file update information in the configuration update field, and the configuration file is stored in the shared storage space of the current orchestration unit; if the configuration update field does not detect that there is configuration information to be updated, a graceful stop operation is performed on the target business process.

[0037] In one embodiment, the restart module is further configured to:

[0038] If a restart file is detected in the shared storage space of the current orchestration unit, the execution directory of the target business process is pointed to the corresponding file storage path in the shared storage space, and the target business process is restarted. The restart file includes an executable file and a configuration file. If the restart file is detected not to exist in the shared storage space, the target business process is restarted.

[0039] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0040] Upon detecting a restart operation instruction for the target service process of the current orchestration unit content device, restart configuration information is extracted from the restart operation instruction; based on the restart configuration information, pre-restart processing is performed on the target service process; after the target service process completes the pre-restart processing, the target service process is restarted in place.

[0041] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0042] Upon detecting a restart operation instruction for the target service process of the current orchestration unit content device, restart configuration information is extracted from the restart operation instruction; based on the restart configuration information, pre-restart processing is performed on the target service process; after the target service process completes the pre-restart processing, the target service process is restarted in place.

[0043] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0044] Upon detecting a restart operation instruction for the target service process of the current orchestration unit content device, restart configuration information is extracted from the restart operation instruction; based on the restart configuration information, pre-restart processing is performed on the target service process; after the target service process completes the pre-restart processing, the target service process is restarted in place.

[0045] The aforementioned container orchestration platform's business process restart method, apparatus, computer equipment, computer-readable storage medium, and computer program product first, upon detecting a restart operation command for the target business process within the current orchestration unit, extracts restart configuration information from the restart operation command; then, performs pre-restart processing on the target business process using the restart configuration information; finally, after the target business process completes the pre-restart processing, it restarts the target business process in situ. Because the restart process involves separate monitoring of the target business process within the current orchestration unit, and upon receiving the restart operation command, it directly completes the restart process... By performing pre-restart processing and in-situ restarts on pairs of target business processes, the system achieves precise restarts of target business processes without affecting the normal operation of other processes within the container. This avoids the need to force a restart of all business processes within the current orchestration unit when restarting a target business process. Therefore, it overcomes the technical drawback that restarting a container with multiple independent or related processes can trigger a forced restart of all processes within the container, leading to resource waste and data consistency risks caused by the restarting of unrelated processes. Thus, it improves the flexibility of restarting business processes on the container orchestration platform. Attached Figure Description

[0046] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1 A deployment diagram illustrating the container rebuilding process for a self-implementing DaemonSet;

[0048] Figure 2 This is a flowchart illustrating a method for restarting a business process in a container orchestration platform, as shown in one embodiment.

[0049] Figure 3 This is a flowchart illustrating a method for restarting business processes in a container orchestration platform, as shown in another embodiment.

[0050] Figure 4 This is a schematic diagram illustrating the framework for restarting a target business process in a container orchestration platform business process restart method according to one embodiment.

[0051] Figure 5 This is a flowchart illustrating different business process restart scenarios for a business process restart method of a container orchestration platform in another embodiment;

[0052] Figure 6 A structural block diagram of a business process restart device for a container orchestration platform;

[0053] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0055] First, it should be understood that container orchestration platforms enable automated deployment, scheduling, lifecycle management, and unified resource allocation for massive numbers of containers to ensure consistent service operation across different environments. Taking Kubernetes as an example, the following terms are explained: 1) Kubernetes is an open-source container orchestration and management platform used to automate the deployment, scaling, and operation of containerized applications. It provides highly scalable, automated container operations and powerful container orchestration capabilities, enabling users to effectively manage large-scale containerized applications; 2) Pod: The smallest deployable orchestration unit created and managed in Kubernetes. Essentially, it is one or more containers, each of which can declare its required computing resources such as CPU, memory, and storage; 3) Pod Orchestration Controller: A type of automated tool used to manage the lifecycle of Pods, ensuring that Pods in the cluster run as expected. These controllers declaratively describe the state of a Pod (specification, number of replicas, etc.) and automatically adjust the actual state of the Pod to match the described state. Common controllers may include Deployment, StatefulSet, and DaemonSet. 4) Sidecar container: A common microservice architecture pattern, usually used in Kubernetes environments to enhance the functionality of the main container. The sidecar container is deployed in a Pod together with the main application container and shares the same network stack and storage resources with the main container.Complete functions such as network proxy, monitoring and log collection, protocol conversion, health check, authentication and authorization; 5) CustomResourceDefinitions: This is an extension of the Kubernetes API. When the default API objects provided by Kubernetes cannot meet the user's needs, the user can use CRDs to create custom API objects. At the same time, the user needs to write a controller component to handle the corresponding CRD; 6) LinuxNamespaces: This is a mechanism provided by the Linux kernel for isolating processes, so that each process in the namespace has an independent view and can be considered to have exclusive access to the entire system resources. This isolation mechanism is one of the foundations of container technology. It allows multiple mutually isolated virtual environments to run on the same host. It mainly includes Network Namespace (network isolation), PID Namespace (process = ID isolation), and Mount Namespace (file system mount point isolation), etc.; 7) In-place Restart: In Kubernetes, this refers to directly restarting the processes in the Pod without changing the lifecycle state of the Pod. This restart method will not cause the Pod to be rescheduled. The container still runs on the same node and retains the original network identifiers (such as IP addresses), storage volumes and other resources.

[0056] Understandably, Kubernetes is a portable, scalable, open-source platform for managing containerized workloads and services. Kubernetes boasts a large and rapidly growing ecosystem, with its services, support, and tools widely used, and has become the de facto standard for cloud computing PaaS layers. Kubernetes provides Pods as the smallest unit that can be created, managed, scheduled, and deployed. Essentially, a Pod is a group (or group of one or more) of containers that can declare the amount of computing resources (CPU, memory, storage, etc.) they require. These containers share the same network stack and storage resources, and can also share Linux namespaces such as PID namespaces through Kubernetes configuration.Application services are deployed and run in Kubernetes as Pods to provide services to the outside world. To accommodate the characteristics of different types of application services and enable them to better migrate to the cloud, Kubernetes implements various Pod controllers to provide orchestration services for Pods. Common orchestration controllers include the following two types: 1) Deployment: As a high-level controller, it manages the deployment of stateless applications. It is one of the most basic controllers in Kubernetes, ensuring that a specified number of stateless application replicas are always running in the cluster. Its features include support for assigning unique network identifiers (such as names) to each Pod, support for label selectors to select a group of Pods based on labels and ensure that the number of these Pods matches the expected number, support for rolling upgrades (allowing for the orderly replacement of old Pod replicas according to identifier order), support for rolling back to previous versions when updates fail, support for version management and history, smooth rolling updates, and support for stable persistent storage volumes. Each Pod can be associated with a unique storage volume. It is often suitable for applications such as databases and caches that require persistent storage and stable network identifiers. 2) DaemonSet: This is used to ensure that a Pod runs on all (or some) nodes in the cluster. The characteristics of a Pod replica are that it supports running a replica of a Pod on all (or some) nodes across the cluster, supports label selectors, supports rolling upgrades, allows for the gradual replacement of old Pod replicas, supports rolling back to previous versions when updates fail, and supports version management and history. It can perform smooth rolling updates and is often suitable for services that need to run on every node, such as log collectors and monitoring agents. Understandably, Pod controllers in Kubernetes generally provide some rolling upgrade capabilities, such as modifying Pod labels or the image version of containers in a Pod, which can trigger a rolling upgrade by the controller. However, Kubernetes does not provide an API interface for restarting container processes in a Pod, either at the Pod controller level or at the Pod level.

[0057] In practical applications, there are often scenarios where it's necessary to restart container processes within a Pod, typically such as: 1. Proactive maintenance operations, restarting business processes to fix program issues, such as clearing cache; 2. Restarting business processes to upgrade to a new version or load new configuration files. While rolling upgrades can achieve the same goals, the essence of a rolling upgrade process is to first delete a certain number of Pod replicas, and then Kubernetes creates, schedules, and deploys the same number of new Pods. The most prominent problem with this is that the Pods need to undergo a rebuilding process, making it impossible to restart and upgrade business processes in place. In real-world scenarios, this can lead to the following issues: Issues: 1) Rebuilding a Pod involves the creation, scheduling, and deployment of a new Pod, which significantly lengthens the time required to restart business processes, especially the time consumed during the scheduling phase and the time consumed during the image download process during deployment, both of which are major time-consuming factors; 2) Rebuilding a Pod changes the Pod's IP address, which increases the complexity of operations and maintenance in some application scenarios, such as client components caching the server's IP address, or the master side of a big data application recording the worker's IP address as a cache; if the Pod's IP address changes, the new IP address must be notified to the parties that need to be aware of it through manual or programmatic means.

[0058] Currently, restarting business processes on container orchestration platforms is typically done within the container. Taking Kubernetes as an example, there are two common restart methods: 1) Liveness probe mechanism: This involves creating a liveness probe for the container. Kubernetes provides a container liveness detection mechanism, specifically, Kubernetes checks the container's health status by executing script commands or using HTTP / TCP protocols. If the liveness detection fails, Kubernetes restarts the container to repair the business process. While this mechanism can restart business processes, it is a passive mechanism, only effective when problems have already occurred within the container. It cannot achieve proactive restarts, such as allowing business processes to actively restart to fix existing problems. 2) Restarting containers using custom resources and custom-implemented DaemonSets, as described above. Figure 1 , Figure 1This diagram illustrates how a custom DaemonSet can be used to rebuild containers. The first step is to programmatically implement a custom client, which is deployed as a DaemonSet on each node of Kubernetes. The client listens to custom resources in the Kubernetes API Server to modify the Kubelet configuration on that node, which in turn restarts the corresponding application containers. The main challenge with this approach is its high implementation difficulty, especially the interaction between the custom client and the Kubelet, which requires a deep understanding of the underlying code details of the Kubelet.

[0059] Analysis reveals the following drawbacks to current methods for restarting business processes within container orchestration platforms: Since restarts are performed at the container level, restarting a container triggers a complete restart of all processes within it. This is not only inflexible but can also lead to problems. For example, if a parent process within a container manages many child processes, it's impossible to restart or upgrade the parent process individually, as restarting the container will restart all processes. A typical scenario is the NodeManager in a big data Yarn service. The NodeManager is responsible for starting and managing big data tasks; if the container containing the NodeManager restarts, all big data tasks will restart, impacting business operations. Furthermore, because containers contain multiple independent or related processes, restarting within a container forces a restart of all processes within it. This can easily lead to resource waste and data consistency risks due to the restarting of unrelated processes. Therefore, there is an urgent need for a method to restart business processes within container orchestration platforms that improves the flexibility of restarting these processes.

[0060] In one embodiment, such as Figure 2As shown, a method for restarting business processes in a container orchestration platform is provided. This embodiment uses a terminal as an example, including but not limited to personal computers, laptops, smartphones, and tablets. The terminal includes an extraction module, a pre-processing module, and a restart module. The extraction module extracts restart configuration information from the restart operation command when a restart operation command for the target business process in the current orchestration unit is detected. The pre-processing module performs restart pre-processing on the target business process based on the restart configuration information. The restart module restarts the target business process in place after the restart pre-processing is completed. Through information interaction between the extraction module, the pre-processing module, and the restart module, the target business process in the current orchestration unit can be monitored individually. Upon receiving the restart operation command for the target business process, the pre-processing and in-place restart of the target business process can be completed directly. This achieves the goal of accurately restarting the target business process without affecting the normal operation of other processes within the container, thus improving the flexibility of restarting business processes in the container orchestration platform. This method can also be applied to servers and systems including terminals and servers, and can be implemented through interaction between the terminal and the server. In this embodiment, the method includes steps 202 to 206. Wherein:

[0061] Step 202: If a restart operation instruction is detected for the target service process of the current orchestration unit content device, the restart configuration information is extracted from the restart operation instruction.

[0062] It should be noted that the current orchestration unit represents the smallest logical carrier in the container orchestration platform that performs scheduling, deployment, and lifecycle management; the lightweight runtime environment within the container orchestration unit is the carrier of the business process. It can be understood that an orchestration unit can contain one or more containers; the restart operation instruction is used to trigger the restart operation of the target business process, and may specifically include structured data of restart-related instruction information; the target business process represents the business process that needs to be restarted; the restart configuration information represents the structured core data set extracted from the restart operation instruction, used to instruct the target business process to complete pre-restart processing (such as version upgrade, configuration update) and in-situ restart, and may specifically include target object location information, restart operation type, version upgrade-specific configuration information, and configuration update-specific information, etc.

[0063] Understandably, taking the Kubernetes container orchestration platform as an example, a custom WorkerRestartController can be defined within the host machine. The WorkerRestartController will be deployed in the same Pod as the business container as a Sidecar container. Its main function is to listen to custom resources of WorkerRestartRequest and perform operations such as updating the configuration of the business process, downloading the new version of the business process, and restarting the business process based on the content of WorkerRestartRequest. In other words, it listens to WorkerRestartRequest information to detect whether there is a restart operation instruction for the target business process of the current orchestration unit container.

[0064] As an example, step 202 includes: if a restart operation instruction for the target service process of the current orchestration unit is detected based on the WorkerRestartRequest information, the restart operation instruction is parsed to obtain restart configuration information.

[0065] Step 204: Perform pre-restart processing on the target business process based on the restart configuration information.

[0066] It should be noted that pre-restart processing refers to the preprocessing operations performed before the target business process is officially restarted to ensure successful restart and environment adaptation.

[0067] As an example, step 204 includes: performing pre-restart processing on the target business process by restarting the configuration information.

[0068] Step 206: After the target business process completes the pre-restart processing, the target business process is restarted in place.

[0069] It should be noted that restarting in place refers to performing a stop-and-start operation on the target business process without changing the current running state of the orchestration unit, rebuilding the container, or interrupting other processes.

[0070] As an example, step 206 includes: restarting the target business process in place after the target business process has completed the pre-restart processing.

[0071] In the aforementioned method for restarting business processes in the container orchestration platform, upon detecting a restart operation command for the target business process within the current orchestration unit, restart configuration information is extracted from the restart operation command. Then, the restart configuration information is used to perform pre-restart processing on the target business process. Finally, after the target business process completes the pre-restart processing, it is restarted in place. Because the target business process is monitored separately within the current orchestration unit, and upon receiving the restart operation command, the pre-restart processing and in-place restart are directly completed, the goal of accurately restarting the target business process without affecting the normal operation of other processes within the container is achieved. This avoids the need to forcibly restart all business processes within the current orchestration unit when restarting the target business process. Therefore, it overcomes the technical shortcomings of containers containing multiple independent or related processes, where a restart operation within a container would trigger a forced restart of all processes within the container, leading to resource waste and data consistency risks due to the restart of unrelated processes. Thus, it improves the flexibility of restarting business processes in the container orchestration platform.

[0072] In one embodiment, such as Figure 3 As shown, based on the restart configuration information, pre-restart processing is performed on the target business process, including:

[0073] Step 302: Parse the restart operation type of the target business process from the restart configuration information.

[0074] It should be noted that the specific pre-restart processing operations differ depending on the type of restart operation. Taking the Kubernetes container orchestration platform as an example, restart operation types can include Restart (process restart) and Upgrade (process version upgrade). The Restart type focuses on configuration updates or fault recovery and does not require changes to the process executable file version. The pre-processing logic mainly involves configuration verification and graceful process shutdown. On the other hand, the Upgrade type focuses on feature iteration or version repair and requires replacement of the executable file in the process. The pre-processing logic mainly involves downloading, verifying, and storing the new version. Differentiated pre-processing ensures the accuracy and adaptability of process restart operations.

[0075] As an example, step 302 includes: parsing the restart configuration information to obtain the restart operation type of the target business process.

[0076] Step 304: Perform a restart pre-operation of the restart operation type on the target business process.

[0077] As an example, step 304 includes: performing the corresponding restart pre-operation on the target business process according to the restart operation type.

[0078] In this embodiment, by parsing the restart operation type of the target business process from the restart configuration information and completing the corresponding restart pre-operation based on the restart operation type, the restart pre-processing logic of the target business process can be adapted to the restart pre-processing logic of the target business process. This ensures the accuracy and adaptability of the process restart operation. Therefore, while laying the foundation for the flexibility of restarting the business processes of the container orchestration platform, it also lays the foundation for the effectiveness of restarting the business processes of the container orchestration platform.

[0079] In one embodiment, performing a restart pre-operation of the type of restart operation on the target business process includes:

[0080] When the restart operation type is process version upgrade, the download address of the new version of the process is parsed from the restart configuration information; the executable file of the new version of the process is downloaded according to the download address; and the executable file is stored in the shared storage space of the current orchestration unit.

[0081] It should be noted that in container orchestration application scenarios, taking the Kubernetes container orchestration platform as an example, custom resources (CRDs) for WorkerRestartRequest can be created. Their main function is to describe which processes in a Pod need to be restarted, and they can also configure new configuration files or version information for the target business processes. Specifically: 1) Define the CRD: WorkerRestartRequest: The WorkerRestartRequest provides information such as the Pod selection method, the name of the business process to be restarted, the version download address, and the configuration files to be updated; 2) Implement the WorkerRestartController programmatically: The main responsibility of the WorkerRestartRequest is to monitor the custom resources for WorkerRestartRequest in the Kubernetes APIServer in real time through Kubernetes' ListAndWatch mechanism, and execute configuration file updates, new version downloads, and process restart operations within the container based on the information in the custom resource.

[0082] Understandably, when the restart operation type is a process version upgrade, in order to ensure the integrity, security, and compatibility of the target business process after restart, and to avoid situations such as process restart failure and data inconsistency caused by improper version replacement, pre-restart operations such as downloading the new version executable file, verifying its integrity and legality, and storing it in shared storage space will be performed.

[0083] As an example, when the restart operation type is a process version upgrade, the restart configuration information is parsed to obtain the download address of the new version of the target business process. Using the download address as an index, the executable file of the new version is retrieved and downloaded. After the executable file passes verification, it is stored in the shared storage space of the current orchestration unit. In this way, by parsing the download address of the new version of the process and downloading the executable file, and storing the executable file in the shared storage space of the current orchestration unit after successful verification, the integrity and data consistency of the new version of the target business process's executable file can be ensured. This also avoids restart failures caused by download anomalies, file tampering, or improper storage paths. Therefore, it provides reliable resource support for in-situ restarts of the target business process, laying the foundation for the flexibility of restarting business processes on the container orchestration platform.

[0084] In one embodiment, performing a restart pre-operation of the type of restart operation on the target business process includes:

[0085] When the restart operation type is process restart, the configuration update field is parsed from the restart configuration information; based on the configuration update field, the target business process is preprocessed for restart.

[0086] It should be noted that when the restart operation type is process restart, since only configuration updates and temporary fault recovery are required, there is no need to change the executable version of the target business process. Furthermore, the current orchestration unit's operating environment is already stable, and there are no complex adaptation requirements such as version compatibility or file replacement. Therefore, simple restart preprocessing is sufficient for the target business process.

[0087] As an example, when the restart operation type is process restart, the restart configuration information is parsed to obtain the configuration update fields; restart preprocessing corresponding to the configuration update fields is then performed on the target business process. This ensures the efficiency of restart preprocessing, reducing the consumption of host system resources during the restart operation and shortening the overall time from preprocessing to in-situ restart. This avoids unnecessary business interruptions caused by over-processing. Therefore, while laying the foundation for the flexibility of restarting business processes on the container orchestration platform, it also simultaneously lays the foundation for improving the efficiency of restarting business processes on the container orchestration platform.

[0088] In one embodiment, preprocessing for restarting the target business process based on the configuration update field includes:

[0089] If the configuration update field detects that there is configuration information to be updated, a configuration file is generated based on the file update information in the container in the configuration update field, and the configuration file is stored in the shared storage space of the current orchestration unit; if the configuration update field does not detect that there is configuration information to be updated, a graceful stop operation is performed on the target business process.

[0090] It should be noted that different restart preprocessing operations will be performed based on the different content types of the configuration update field. Specifically, if the configuration update field carries specific configuration information to be updated, such as the file path within the container and the new configuration content, then the configuration file generation and storage operations will be performed. If the configuration update field does not carry any configuration information to be updated (e.g., the field is empty or marked as not needing to be updated), then a graceful stop operation will be performed directly. A graceful stop operation means that before terminating the target business process, it waits for the process to complete the business request it is currently processing, closes the network connection, and releases the system resources it occupies, rather than directly forcibly killing the process. This can minimize problems such as data loss, business interruption, or resource leakage. The file update information within the container includes the file path and file content within the container.

[0091] As an example, if the configuration update field detects that there is configuration information to be updated, a configuration file is generated based on the container file update information in the configuration update field, and the configuration file is stored in the shared storage space of the current orchestration unit. If the configuration update field does not detect that there is configuration information to be updated, a graceful shutdown operation is performed on the target business process. In this way, by taking different restart preprocessing operations based on different content types of the configuration update field, it is possible to match differentiated process restart requirements. Therefore, by improving the accuracy of restart preprocessing for the target business process, the foundation is laid for improving the flexibility of restarting business processes on the container orchestration platform.

[0092] In one embodiment, restarting the target service process in place includes:

[0093] If a restart file is detected in the shared storage space of the current orchestration unit, the execution directory of the target business process is pointed to the corresponding file storage path in the shared storage space, and the target business process is restarted. The restart file includes an executable file and a configuration file. If no restart file is detected in the shared storage space, the target business process is restarted.

[0094] It should be noted that different restart steps will be taken depending on the type of restart files stored in the shared storage space; restart files include configuration files generated when the restart operation type is process restart and executable files downloaded when the restart operation type is process version upgrade.

[0095] As an example, if a restart file is detected in the shared storage space of the current orchestration unit, the execution directory of the target business process is pointed to the corresponding file storage path in the shared storage space, and the target business process is restarted. The restart file includes both executable files and configuration files. If no restart file is detected in the shared storage space, the target business process is restarted. This adapts to different restart scenarios of the target business process, employing different restart operations to complete the restart, thereby further improving the flexibility of restarting the target business process.

[0096] In one feasible approach, refer to Figure 4 , Figure 4 This is a schematic diagram of a framework for restarting a target business process. A WorkerRestartController is deployed in the sidecar container to monitor custom resource information and manage configuration updates, restarts, and upgrades of the business process. The sidecar container and the business container containing the business process share storage space, and both are implemented within the Pod. The framework can achieve the following: 1) It can proactively trigger the in-place restart of the business process within the Pod through configuration, avoiding Pod rebuilding and significantly saving time on business restarts and upgrades; 2) It can restart or upgrade any number of processes within the container without restarting the container itself; 3) The implementation is relatively simple, reducing the mental burden on developers who do not need to understand the code principles and configurations of Kubernetes core components.

[0097] In one feasible approach, refer to Figure 5 , Figure 5This is a flowchart illustrating different business process restart scenarios. Specifically, it listens for WorkerRestartRequest messages to determine if the current pod is restarting a business process. It then determines whether the action is Restart or Upgrade. If it's Upgrade, it downloads the new version of the process based on the binaryPath and stores it in a temporary directory. If it's Restart, it checks if any configuration files need updating. If so, it prepares a new configuration file based on the path and content in the config file and stores the new version in a temporary location. Otherwise, it gracefully stops the process and then checks again to see if a new version has been downloaded or the configuration file updated. If so, it prepares the new version and configuration file (by creating symbolic links pointing the process's execution directory to the directory containing the new version and configuration file). Otherwise, it starts a new process. This can be described as follows: upon detecting a restart command for the target business process of the current orchestration unit, it extracts restart configuration information from the restart command and parses the target business process from the restart configuration information. The restart operation type for the service process is determined as follows: If the restart operation type is a process version upgrade, the download address of the new process version is parsed from the restart configuration information; the executable file of the new process version is downloaded based on the download address; the executable file is stored in the shared storage space of the current orchestration unit. If the restart operation type is a process restart, the configuration update field is parsed from the restart configuration information; if configuration information to be updated is detected in the configuration update field, a configuration file is generated based on the container file update information in the configuration update field, and the configuration file is stored in the shared storage space of the current orchestration unit; if no configuration information to be updated is detected in the configuration update field, a graceful stop operation is performed on the target service process; finally, when restarting the target service process: if a restart file is detected in the shared storage space of the current orchestration unit, the execution directory of the target service process is pointed to the corresponding file storage path in the shared storage space, and the target service process is restarted. The restart file includes the executable file and the configuration file; if no restart file is detected in the shared storage space, the target service process is restarted.

[0098] Because the restart process of the target business process is monitored separately within the current orchestration unit container, and upon receiving the restart command for the target business process, the pre-restart processing and in-situ restart of the target business process are completed directly, the goal of accurately restarting the target business process without affecting the normal operation of other processes within the container can be achieved. This avoids the need to forcibly restart all business processes within the current orchestration unit container when restarting the target business process. Therefore, it overcomes the technical defect that when a container contains multiple independent or related processes, a restart operation within the container will trigger a forced restart of all processes within the container, which may lead to resource waste and data consistency risks caused by the restart of unrelated processes. Thus, it improves the flexibility of restarting business processes on the container orchestration platform.

[0099] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0100] Based on the same inventive concept, this application also provides a container orchestration platform business process restart device for implementing the above-mentioned container orchestration platform business process restart method. The solution provided by this device is similar to the implementation described in the above method. Therefore, the specific limitations of one or more container orchestration platform business process restart device embodiments provided below can be found in the limitations of the container orchestration platform business process restart method described above, and will not be repeated here.

[0101] In one exemplary embodiment, such as Figure 6 As shown, a business process restart device for a container orchestration platform is provided, comprising: an extraction module 401, a pre-processing module 402, and a restart module 403, wherein:

[0102] The extraction module 401 is used to extract restart configuration information from the restart operation instruction when a restart operation instruction for the target service process of the current orchestration unit content device is detected.

[0103] The pre-processing module 402 is used to perform pre-restart processing on the target business process based on the restart configuration information;

[0104] The restart module 403 is used to restart the target business process in place after the target business process has completed the pre-restart processing.

[0105] In one embodiment, the preprocessing module 402 is further configured to:

[0106] Extract the restart operation type of the target business process from the restart configuration information; perform the restart pre-operation of the restart operation type on the target business process.

[0107] In one embodiment, the preprocessing module 402 is further configured to:

[0108] When the restart operation type is process version upgrade, the download address of the new version of the process is parsed from the restart configuration information; the executable file of the new version of the process is downloaded according to the download address; and the executable file is stored in the shared storage space of the current orchestration unit.

[0109] In one embodiment, the preprocessing module 402 is further configured to:

[0110] When the restart operation type is process restart, the configuration update field is parsed from the restart configuration information; based on the configuration update field, the target business process is preprocessed for restart.

[0111] In one embodiment, the preprocessing module 402 is further configured to:

[0112] If the configuration update field detects that there is configuration information to be updated, a configuration file is generated based on the file update information in the container in the configuration update field, and the configuration file is stored in the shared storage space of the current orchestration unit; if the configuration update field does not detect that there is configuration information to be updated, a graceful stop operation is performed on the target business process.

[0113] In one embodiment, the restart module 403 is further configured to:

[0114] If a restart file is detected in the shared storage space of the current orchestration unit, the execution directory of the target business process is pointed to the corresponding file storage path in the shared storage space, and the target business process is restarted. The restart file includes an executable file and a configuration file. If no restart file is detected in the shared storage space, the target business process is restarted.

[0115] The modules in the business process restart device of the aforementioned container orchestration platform can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0116] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7 As shown. The computer device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a method for restarting business processes on a container orchestration platform. Those skilled in the art will understand that... Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0117] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0118] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0119] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0120] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0121] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0122] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for restarting business processes in a container orchestration platform, characterized in that, The method includes: If a restart operation instruction is detected for the target service process of the current orchestration unit content device, restart configuration information is extracted from the restart operation instruction; Based on the restart configuration information, perform pre-restart processing on the target business process; After the target business process completes the pre-restart processing, the target business process is restarted in place.

2. The method according to claim 1, characterized in that, The step of performing pre-restart processing on the target service process based on the restart configuration information includes: The restart operation type of the target business process is parsed from the restart configuration information; Perform the restart pre-operation of the restart operation type on the target business process.

3. The method according to claim 2, characterized in that, The pre-restart operation performed on the target business process of the restart operation type includes: When the restart operation type is a process version upgrade, the download address of the new version of the process is parsed from the restart configuration information; Download the executable file of the new version of the process from the provided download address; The executable file is stored in the shared storage space of the current orchestration unit.

4. The method according to claim 2, characterized in that, The pre-restart operation performed on the target business process of the restart operation type includes: When the restart operation type is process restart, the configuration update field is parsed from the restart configuration information; Based on the configuration update fields, perform a restart preprocessing for the target business process.

5. The method according to claim 4, characterized in that, The step of performing restart preprocessing on the target business process based on the configuration update field includes: If configuration information to be updated is detected in the configuration update field, a configuration file is generated based on the container file update information in the configuration update field, and the configuration file is stored in the shared storage space of the current orchestration unit. If the configuration information to be updated is not found in the configuration update field, a graceful stop operation is performed on the target business process.

6. The method according to claim 1, characterized in that, The in-situ restart of the target service process includes: If a restart file is detected in the shared storage space of the current orchestration unit, the execution directory of the target business process is pointed to the corresponding file storage path in the shared storage space, and the target business process is restarted. The restart file includes an executable file and a configuration file. If the restart file is not found in the shared storage space, the target business process is restarted.

7. A business process restart device for a container orchestration platform, characterized in that, The device includes: The extraction module is used to extract restart configuration information from the restart operation instruction when a restart operation instruction for the target service process of the current orchestration unit content device is detected. The pre-processing module is used to perform pre-restart processing on the target business process according to the restart configuration information; The restart module is used to restart the target business process in place after the target business process has completed the pre-restart processing.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images