Method and system for extending Pod life cycle

Abstract

The invention provides a Pod life cycle extension method and system, and the method comprises the steps: enabling an extension assembly to recognize a Pod scheduled to a working node, so as to determine a target Pod on the working node; when the Kubelet deployed by the working node performs life cycle management on the target Pod, the extension component suppresses the native operation behavior of the Kubelet; the extension component executes a life cycle management operation corresponding to a life cycle management instruction according to the received life cycle management instruction for the target Pod, and records state information of the target Pod; the life cycle management operation comprises one or a combination of any more of a starting operation, a closing operation and a restarting operation based on an original root file system of the target Pod, and a creation operation and a destruction operation of the target Pod are executed by Kubelet. According to the invention, life cycle extension management of the target Pod is realized.

Description

Technical Field

[0001] This invention relates to the field of containerization technology, and more particularly to a method, apparatus, electronic device, and computer-readable storage medium for extending the lifecycle of a Pod. Background Technology

[0002] Kubernetes, as a mainstream container orchestration system, provides a declarative API and a unified control model for describing, managing, and running distributed systems composed of multiple containers. It uses components like Kubelet to strictly manage the lifecycle of Pods, ensuring high availability and scalability of applications. Kubelet's design is mandatory and global; it maintains eventual consistency by continuously comparing the expected and actual states of Pods and forcibly correcting any discrepancies. However, this general "rebuild and heal" design pattern has limitations when facing specific types of business scenarios. These limitations mainly stem from two issues: data state loss and resource overhead and performance pressure.

[0003] In the native Kubernetes model, a Pod's root filesystem (roofts) is considered stateless and can be destroyed and rebuilt at any time. For certain special businesses (such as cloud phones or applications running traditional software), their core system data or runtime state are stored directly in the container's roofts, rather than persistent volumes. When a Pod is destroyed and rebuilt by Kubelet due to failure, node scheduling, or rolling updates, the brand-new roofts will cause this sensitive data to be permanently lost, compromising data consistency in the business.

[0004] In large-scale business scenarios, the simultaneous rebuilding of a large number of Pods can lead to significant resource overhead, including frequent image fetching, huge disk I / O pressure caused by roofts creation, and the allocation and release of network resources. This not only affects cluster performance but may also exacerbate the instability of container orchestration systems under resource constraints.

[0005] In existing technologies, users typically use persistent volumes (PVs) to store data that needs to be persisted. However, this approach cannot solve the problem of persisting system files, temporary runtime states, and other data that must be stored in roofts. Another approach is to modify the source code of Kubelet or container runtime, but this would break the standardization of Kubernetes, introduce extremely high maintenance costs and upgrade risks, and lack universality.

[0006] Therefore, it is necessary to improve the management scheme for the Pod lifecycle.

[0007] It should be noted that the above description of the background technology is only for the purpose of providing a clear and complete explanation of the technical solutions of the present invention and facilitating understanding by those skilled in the art. It should not be assumed that the above technical solutions are known to those skilled in the art simply because they have been described in the background section of the present invention. Summary of the Invention

[0008] The purpose of this invention is to solve the problems of data state loss, resource overhead, and performance pressure in the existing Pod lifecycle management under certain scenarios.

[0009] To achieve the above objectives, in a first aspect, the present invention provides a method for extending the lifecycle of a Pod, applied in a container orchestration cluster containing a control node and worker nodes, wherein an extension component is deployed on the worker nodes, the method comprising:

[0010] The extension component identifies the Pods scheduled to the worker nodes to determine the target Pods on the worker nodes. The target Pods are those marked as needing lifecycle extension management.

[0011] When the Kubelet deployed on the worker node performs lifecycle management on the target Pod, the extended component suppresses the native operation behavior of the Kubelet;

[0012] The extended component executes the lifecycle management operation corresponding to the received lifecycle management instruction for the target Pod, and records the status information of the target Pod;

[0013] The lifecycle management operations include one or any combination of startup, shutdown, and restart operations based on the original root file system of the target Pod, and the creation and destruction operations of the target Pod are executed by the Kubelet.

[0014] As a further improvement of the present invention, the lifecycle management operation corresponding to the execution of the lifecycle management instruction includes:

[0015] Upon receiving a shutdown command for the target Pod, the business application container in the target Pod is stopped, and the Infra container, network namespace, and root file system of the target Pod are kept running or mounted and are not released.

[0016] As a further improvement of the present invention, the lifecycle management operation corresponding to the execution of the lifecycle management instruction includes:

[0017] When the target Pod is in a closed state, upon receiving a startup command for the target Pod, the business application container is restarted based on the original root file system of the target Pod and the running Infra container.

[0018] As a further improvement of the present invention, the lifecycle management operation corresponding to the execution of the lifecycle management instruction includes:

[0019] Upon receiving a restart command for the target Pod, the system sequentially performs shutdown and startup operations on the business application container based on the original root file system of the target Pod.

[0020] As a further improvement of the present invention, the method further includes:

[0021] After the working node fails and recovers, the extension component scans all Pods on the working node. When the scan finds that the Pod is the target Pod, the extension component performs the corresponding state recovery operation.

[0022] As a further improvement of the present invention, the execution of the corresponding state recovery operation includes: network recovery operation;

[0023] The network recovery operation includes: if the status information of the target Pod indicates that the business application container is running, the extended component calls the container network interface plugin, restores the network connection of the target Pod based on the network configuration information of the Infra container of the target Pod, and starts the business application container.

[0024] As a further improvement of the present invention, the extended component suppresses the native operation behavior of the Kubelet, including:

[0025] The extended component modifies the synchronization state information of the target Pod within the Kubelet, so that the Kubelet determines that the target Pod is in the desired state.

[0026] Secondly, the present invention provides an apparatus for extending the lifecycle of a Pod, deployed on a worker node of a container orchestration cluster, the apparatus comprising:

[0027] The identification module is used to identify the Pods scheduled to the worker nodes in order to determine the target Pods on the worker nodes, wherein the target Pods are the Pods that need to be managed for lifecycle extension.

[0028] The behavior suppression module is used to suppress the native operation behavior of the Kubelet when the Kubelet deployed on the worker node performs lifecycle management on the target Pod;

[0029] The extended management module is used to execute lifecycle management operations corresponding to the received lifecycle management instructions for the target Pod, and record the status information of the target Pod.

[0030] The lifecycle management operations include one or any combination of startup, shutdown, and restart operations based on the original root file system of the target Pod, and the creation and destruction operations of the target Pod are executed by the Kubelet.

[0031] Thirdly, the present invention provides an electronic device, comprising:

[0032] A processor, a storage device comprising at least one storage unit, and

[0033] A communication bus that establishes a communication connection between the processor and the storage device;

[0034] The processor is used to execute one or more programs stored in the storage device to implement the method for extending the Pod lifecycle as described in any of the foregoing inventions.

[0035] Fourthly, the present invention provides a computer-readable storage medium.

[0036] The computer-readable medium stores computer program instructions that, when read and executed by a processor, perform the method for extending the Pod lifecycle as described in any of the foregoing inventions.

[0037] Compared with the prior art, the beneficial effects of the present invention are:

[0038] The extension component identifies the Pods scheduled to worker nodes to determine the target Pod on the worker node. When the Kubelet deployed on the worker node performs lifecycle management on the target Pod, the extension component suppresses the native Kubelet behavior. The extension component executes the lifecycle management operations corresponding to the received lifecycle management instructions for the target Pod and records the target Pod's state information. The target Pod is the Pod on the worker node marked as requiring extended lifecycle management. Lifecycle management operations include one or more combinations of start, stop, and restart operations based on the target Pod's original root file system. The creation and destruction operations of the target Pod are executed by the Kubelet. Due to the intervention of the extension component and the suppression of Kubelet behavior, the start, stop, and restart operations of the target Pod are all based on the target Pod's original root file system (i.e., rootfs), thus reusing the original root file system and avoiding the problem of system data loss caused by rebooting the rootfs. Attached Figure Description

[0039] Figure 1 This is a topology diagram of the computer system shown in this invention;

[0040] Figure 2 A schematic diagram illustrating the steps of a method to extend the Pod lifecycle;

[0041] Figure 3 A topology diagram of a device that extends the lifecycle of a Pod;

[0042] Figure 4 This is a topology diagram of electronic devices;

[0043] Figure 5 A topology diagram of a computer-readable storage medium. Detailed Implementation

[0044] The present invention will now be described in detail with reference to the embodiments shown in the accompanying drawings. However, it should be noted that these embodiments are not intended to limit the present invention. Equivalent changes or substitutions in function, method, or structure made by those skilled in the art based on these embodiments are all within the scope of protection of the present invention.

[0045] Please refer to Figure 1 and Figure 2As shown, this invention illustrates a specific implementation of a method for extending the lifecycle of a Pod (hereinafter referred to as the "Method"). The application scenario of this method is in a container orchestration cluster (such as a computer system 100) containing a control node 10 and worker nodes 20, where lifecycle extension management is performed on non-traditional Pods (i.e., target Pod 231 below) that require lifecycle extension management. Specifically, during the lifecycle extension management process, the native operation behavior of Kubelet 21 is suppressed, and lifecycle extension management of target Pod 231 is performed based on the extension component 22. This ensures the reuse of the root file system (i.e., rootfs), avoids data loss caused by rebooting the root file system, and thus solves the problems of data state loss, resource overhead, and performance pressure associated with existing Pod lifecycle management in specific scenarios.

[0046] It should be noted that the method provided in this embodiment of the invention can run on a computer system 100 with multiple nodes (including control node 10 and worker nodes 20), or on a cloud computing platform (not shown) composed of multiple such computer systems 100. This cloud computing platform can be understood as a resource service system formed by integrating computing devices such as hyper-converged appliances, servers, data centers, or mobile terminals through virtualization technology. For the sake of brevity, the following embodiments will mainly use a computer system 100 containing multiple nodes as an example. However, it should be clarified that this is not a limitation of the invention, and the scope of protection of the invention also covers the implementation in the cloud computing platform. The computer system 100 or the cloud computing platform adopts a container orchestration cluster architecture. Preferably, the container orchestration cluster is a Kubernetes architecture or an OpenShift architecture. It is understood that any container orchestration system with components equivalent to the Kubelet function in Kubernetes and responsible for the lifecycle management of workloads on nodes is applicable to this invention, and this embodiment does not limit the specific architecture selection.

[0047] For example, the reference Figure 1 As shown, a control node 10 and a worker node 20 are deployed on the computer system 100. The worker node 20 is equipped with a Kubelet 21, an extension component 22, and a Pod 23. The Pod 23 includes a target Pod 231 and other Pods 232. The Kubelet 21 and the extension component 22 work together to manage the lifecycle of the target Pod 231.

[0048] It should be noted that this embodiment involves several fundamental concepts in the field of container orchestration. For ease of understanding, the key terms are explained below.

[0049] Pod23: The smallest atomic unit that can be scheduled and managed in a container orchestration cluster. A Pod encapsulates one or more tightly coupled application containers (i.e., business application containers) that share storage resources and network namespaces. In Kubernetes and similar architectures, Pods are the direct objects of workload deployment and lifecycle management. A Pod typically contains a special Infrastructure container that holds a shared Linux namespace (such as a network namespace), and one or more business application containers that carry the specific business logic.

[0050] Kubelet21 is a proxy daemon running on each worker node of a container orchestration cluster, serving as the core bridge between node resources and the cluster control plane. Its main responsibilities include: state synchronization (i.e., continuously obtaining the expected state of Pods scheduled to this node from the cluster control plane (such as the API Server), lifecycle management (i.e., driving the underlying container runtime through standard container runtime interfaces to execute specific container operations to ensure that the actual state of Pods on this node matches the expected state. These operations follow a "final state-oriented" control loop logic), and resource and health reporting (i.e., reporting the resource usage and health status of this worker node and Pods to the control plane).

[0051] Extension Component 22: This is the core functional entity of the present invention, and can be referred to as Extender in this embodiment. It is an independently running software program deployed and running on each worker node, working in conjunction with Kubelet 21. Extension Component 22 is configured to perform the following functions to achieve extended lifecycle management of the target Pod 231: identification and management (i.e., scanning all Pods 23 on the worker node 10 to identify the target Pod 231), behavioral intervention (i.e., suppressing the native operation behavior of Kubelet 21 for the target Pod 231 to prevent it from performing standard lifecycle management operations on the target Pod 231), extended operation (i.e., executing the lifecycle management operation corresponding to the received lifecycle management instruction for the target Pod 231), and self-healing recovery (i.e., calling the container network interface plugin to restore the network connection of the target Pod 231 based on the network configuration information of the Infra container of the target Pod 231 and starting the business application container).

[0052] In particular, extension component 22 does not replace Kubelet 21, but rather forms a collaborative and complementary relationship with it. Kubelet 21 is responsible for the basic framework for maintaining cluster final state consistency (i.e., the creation and destruction operations of target Pod 231), while extension component 22, within this framework, provides target Pod 231 with a stateful, runtime-context-preserving, fine-grained lifecycle management capability (i.e., the start, shutdown, and restart operations of target Pod 231), thereby solving the problem of root file system data loss caused by Pod reconstruction in the standard model.

[0053] In addition, in a specific implementation, the extension component 22 can run on the worker node 20 as a system daemon or a managed target Pod 231 (e.g., deployed via DaemonSet).

[0054] Specifically, participants Figure 2 As shown, the method includes the following steps S1 to S3.

[0055] Step S1: Extended component 22 identifies the Pod scheduled to worker node 20 to determine the target Pod 231 on worker node 20.

[0056] Step S2: When Kubelet21 deployed on worker node 20 performs lifecycle management on target Pod231, extension component 22 suppresses the native operation behavior of Kubelet21.

[0057] Step S3: The extended component 22 executes the lifecycle management operation corresponding to the received lifecycle management instruction for the target Pod 231, and records the status information of the target Pod 231.

[0058] More specifically, the target Pod231 is a Pod in worker node 20 that is marked as needing lifecycle extension management. The lifecycle management operations include one or any combination of startup, shutdown and restart operations based on the original root file system of the target Pod231. The creation and destruction operations of the target Pod231 are executed by Kubelet21.

[0059] Because Kubelet21's control loop for Pods is mandatory and global, Pods need to be categorized using namespaces, tags, annotations, etc., without disrupting the overall structure. Traditional business services (i.e., Pods 232 other than the target Pod 231) are still managed by Kubelet21, while the lifecycle management of non-traditional business services (i.e., the target Pod 231) is partially maintained by the extension component 22. The behavior of extension component 22 does not deviate from the specifications defined by CRI; rather, it encapsulates a series of extended operations based on the CRI specifications. For non-traditional business services, the creation and destruction of the target Pod231 are still handled by Kubelet21. However, during real-time synchronization of the target Pod231, the native operation behavior of Kubelet21 needs to be suppressed and managed by the extension component 22. The extension component 22 will perform start, stop, and restart operations on the target Pod231 according to specific lifecycle management instructions, and record the state information of the target Pod231 (i.e., the behavior of this operation) to achieve extended lifecycle management of the target Pod231. In addition, due to the intervention of the extension component 22 and the suppression of Kubelet21 behavior, the start, stop, and restart operations of the target Pod231 are all based on the original root file system (i.e., rootfs) of the target Pod231. Therefore, the original root file system can be reused, avoiding the data loss problem caused by rebooting the root file system.

[0060] It should be noted that lifecycle management commands are initiated by users through the management platform, or triggered by the automation policy component within Kubernetes according to preset rules.

[0061] Furthermore, the extension component 22 suppresses the native operation behavior of Kubelet 21, including: the extension component 22 modifies the synchronization state information of the target Pod 231 in Kubelet 21, so that Kubelet 21 determines that the target Pod 231 is in the desired state, thereby suppressing the native operation behavior of Kubelet 21 on the target Pod 231.

[0062] In one implementation, a shutdown operation is performed on the target Pod231. Step S3 involves performing the lifecycle management operation corresponding to the lifecycle management instruction, including: upon receiving a shutdown instruction for the target Pod231, stopping the business application container in the target Pod231, and keeping the Infra container, network namespace, and root file system of the target Pod231 running or mounted, without releasing them.

[0063] In one implementation, a startup operation is performed on the target Pod231. Step S3 involves performing the lifecycle management operation corresponding to the lifecycle management instruction, including: when the target Pod231 is in a shut-down state, upon receiving a startup instruction for the target Pod231, restarting the business application container based on the original root file system of the target Pod231 and the running Infra container.

[0064] In one implementation, a restart operation is performed on the target Pod231. Step S3 involves performing the lifecycle management operation corresponding to the lifecycle management instruction, including: upon receiving a restart instruction for the target Pod231, sequentially performing shutdown and startup operations on the business application container based on the original root file system of the target Pod231.

[0065] In one implementation, the method further includes a fault recovery operation. The fault recovery operation includes: after a worker node 20 fails and recovers, the extension component 22 scans all Pods on the worker node 22, and when the scanned Pod is the target Pod 231, the extension component 22 performs the corresponding state recovery operation.

[0066] Furthermore, the corresponding state recovery operations include: network recovery operations. The network recovery operations include: if the state information of the target Pod231 indicates that the business application container is running, the extended component 22 calls the container network interface plugin, based on the network configuration information of the target Pod231's Infra container, to restore the network connection of the target Pod231 and start the business application container.

[0067] It's important to note that because the Kubernetes Pod model is divided into Infra containers and application containers, Kubelet21 maintains the lifecycle of both types of containers by default. However, after suppressing Kubelet21's native operational behavior, this responsibility falls to the extension component 22. A particularly typical scenario is that after worker node 20 crashes and recovers, it needs to automatically scan all Pods on worker node 20 and determine whether intelligent recovery is necessary based on the subjectivity of the behavior.

[0068] In addition, the target Pod231 will lose its network information after the fault recovery. Since the container network allocation is performed during the target Pod's creation phase, and the creation process is not executed during recovery, it is necessary to restore its network separately. Specifically, based on the network configuration information bound to the Infra container, the CNI Plugin is called to rejoin the network. By leveraging the mechanism of the Infra container and the application container sharing the network stack, the container network fault recovery is achieved.

[0069] The method disclosed in the present invention can be applied to the cloud mobile phone service scenario. The cloud mobile phone is hosted in Kubernetes in the form of a Pod, and user data is persisted in the form of a persistent volume. However, the mobile phone system data is limited by the Android model and cannot be stored in the persistent volume (i.e., PV). This part of the data is often stored in the rootfs of the Pod. Therefore, after the Pod is rebuilt, the system data is lost. After introducing the extension component 22, the rebuild operation of the Pod is replaced by a restart operation. In the restart operation, the Pod reuses the original rootfs, thus ensuring data consistency.

[0070] The method disclosed in the present invention can also be applied to achieve peak shaving and valley filling of cluster resource scheduling. In Kubernetes, after a Pod is destroyed and rebuilt, the Pod will be reallocated resources. When the cluster business scale is heavy, the resource overhead pressure brought by a large number of simultaneous rebuilds cannot be ignored. Under the design of the extension component 22, the Pod can be in a closed state, but the underlying sandbox environment, network resources, etc. do not need to be released, and the resource overhead can be minimized when starting. In short, when the cluster resources are紧张, the low-priority application Pods can be closed through the extension component 22 to release computing resources; when the cluster resources are appropriate, the Pods can be started through the extension component 22 again, and the started Pods maintain the original resource allocation identifier and rootfs data.

[0071] In summary, the present invention mainly has the following technical effects compared with the prior art: First, the root file system in the prior art is a stateless file system. With the destruction of the Pod, the root file system is released, and the data stored in the root file system is also lost; while the root file system in the present invention can be made persistent in a stateful manner according to the application scenario, avoiding data loss in sensitive services. Second, due to the persistent feature of the root file system, it is possible to avoid problems such as excessive disk I / O pressure caused by rebuilding the root file system in a large-scale Pod rebuild scenario. Third, by means of the shutdown and startup of the Pod, it is possible to achieve peak shaving and valley filling of the Kubernetes resource utilization rate. For applications with lower priorities, they can be temporarily shut down when the cluster resources are紧张 and started when appropriate, without modifying the original resource identifier that has been allocated, ensuring the consistency of resources and data before and after.

[0072] Based on the same inventive concept, the present invention also discloses a system for extending the Pod life cycle (hereinafter referred to as "system"), which includes: a device for extending the Pod life cycle 200, an electronic device 600, and a computer-readable storage medium 700.

[0073] See Figure 3As shown in the figure, the device 200 is deployed on the worker node 30 of the container orchestration cluster. The device 200 includes: an identification module 201, a behavior inhibition module 202, and an extension management module 203. The identification module 201 is used to identify the Pods scheduled to the worker node 30 to determine the target Pods on the worker node 30. The behavior inhibition module 202 is used to inhibit the native operation behaviors of the Kubelet when the Kubelet deployed on the worker node 30 performs life cycle management on the target Pods. The extension management module 203 executes the life cycle management operations corresponding to the life cycle management instructions according to the received life cycle management instructions for the target Pods, and records the status information of the target Pods.

[0074] Among them, the target Pods are the Pods marked as needing life cycle extension management in the worker node 30. The life cycle management operations include one or any combination of startup operations, shutdown operations, and restart operations based on the original root file system of the target Pods. The creation operations and destruction operations of the target Pods are executed by the Kubelet.

[0075] It should be noted that the logic contained in step S1 in the foregoing method for extending the life cycle of a Pod is implemented by the identification module 201 in a device 200 for extending the life cycle of a Pod; the logic contained in step S2 in the foregoing method for extending the life cycle of a Pod is implemented by the behavior inhibition module 202 in a device 200 for extending the life cycle of a Pod; the logic contained in step S3 in the foregoing method for extending the life cycle of a Pod is implemented by the extension management module 203 in a device 200 for extending the life cycle of a Pod.

[0076] See Figure 4 As shown in the figure, the electronic device 600 includes: a processor 61, a memory 62, and a computer program stored in the memory 62 and configured to be executed by the processor 61. When the processor 61 executes the foregoing computer program, it executes the steps in the foregoing implementation method for extending the life cycle of a Pod.

[0077] Specifically, the memory 62 consists of several storage units, that is, storage units 621 to storage unit 62j, where the parameter j takes a positive integer greater than or equal to 2. The processor 61 and the memory 62 are both connected to the system bus 63. The form of the system bus 63 does not need to be specifically limited. For example, I 2C bus, SPI bus, SCI bus, PCI bus, PCI-c bus, ISA bus, etc., and can be reasonably changed according to the specific type and application scenario requirements of the electronic device 600. Since the system bus 63 is not the inventive point of this application, it will not be elaborated in this application. The storage unit (i.e., storage units 621 to 62j) can be a physical storage unit, so that the electronic device 600 can be understood as a physical computer or a computer cluster or a cluster server; at the same time, the storage unit (i.e., storage units 621 to 62j) can also be a virtual storage unit, for example, a virtual storage space formed by underlying virtualization technology based on a physical storage device, so that the electronic device 600 can be configured as a virtual device such as a virtual server or a virtual cluster.

[0078] In addition, if the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that makes a contribution to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute all or part of the steps of the method disclosed in each embodiment of the present invention. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), or optical discs that can store program codes.

[0079] See Figure 5 As shown, the computer-readable medium 700 can be configured in a physical computer, server, server cluster, or data center as a whole or in part. In this embodiment, a computer-readable medium 700 stores computer program instructions 701. When the computer program instructions 701 are read and run by a processor 702, the steps in the method of extending the Pod life cycle as described above are executed.

[0080] Optionally, the computer-readable medium 700 can be configured as a server, and the server runs on a physical device used to build a private cloud, hybrid cloud, or public cloud. The computer-readable medium 700 can also be configured as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc. The computer-readable medium 700 is used to store a program, which, upon receiving an execution instruction, the processor 702 executes the aforementioned method for extending the Pod lifecycle.

[0081] Meanwhile, the processor 702 disclosed in this embodiment may be an integrated circuit chip with signal processing capabilities. The processor 702 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor.

[0082] The detailed descriptions listed above are merely specific descriptions of feasible embodiments of the present invention, and are not intended to limit the scope of protection of the present invention. All equivalent embodiments or modifications made without departing from the spirit of the present invention should be included within the scope of protection of the present invention.

[0083] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0084] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for extending the lifecycle of a Pod, applied in a container orchestration cluster containing a control node and worker nodes, wherein extension components are deployed on the worker nodes. Its features are, The method includes: The extension component identifies the Pods scheduled to the worker nodes to determine the target Pods on the worker nodes. The target Pods are those marked as needing lifecycle extension management. When the Kubelet deployed on the worker node performs lifecycle management on the target Pod, the extended component suppresses the native operation behavior of the Kubelet; The extended component executes the lifecycle management operation corresponding to the received lifecycle management instruction for the target Pod, and records the status information of the target Pod; The lifecycle management operations include one or any combination of startup, shutdown, and restart operations based on the original root file system of the target Pod, and the creation and destruction operations of the target Pod are executed by the Kubelet.

2. The method according to claim 1, characterized in that, The lifecycle management operations corresponding to the execution and the lifecycle management instructions include: Upon receiving a shutdown command for the target Pod, the business application container in the target Pod is stopped, and the Infra container, network namespace, and root file system of the target Pod are kept running or mounted and are not released.

3. The method according to claim 2, characterized in that, The lifecycle management operations corresponding to the execution and the lifecycle management instructions include: When the target Pod is in a closed state, upon receiving a startup command for the target Pod, the business application container is restarted based on the original root file system of the target Pod and the running Infra container.

4. The method according to claim 1, characterized in that, The lifecycle management operations corresponding to the execution and the lifecycle management instructions include: Upon receiving a restart command for the target Pod, the system sequentially performs shutdown and startup operations on the business application container based on the original root file system of the target Pod.

5. The method according to claim 1, characterized in that, The method further includes: After the worker node fails and recovers, the extension component scans all Pods on the worker node. When the scan finds that the Pod is the target Pod, the extension component performs the corresponding state recovery operation.

6. The method according to claim 5, characterized in that, The execution of the corresponding state recovery operation includes: network recovery operation; The network recovery operation includes: if the status information of the target Pod indicates that the business application container is running, the extended component calls the container network interface plugin, restores the network connection of the target Pod based on the network configuration information of the Infra container of the target Pod, and starts the business application container.

7. The method according to any one of claims 1 to 6, characterized in that, The extended component suppresses the native Kubelet operation behavior, including: The extended component modifies the synchronization state information of the target Pod within the Kubelet, so that the Kubelet determines that the target Pod is in the desired state.

8. An apparatus for extending the lifecycle of a Pod, deployed on a worker node of a container orchestration cluster, characterized in that, The device includes: The identification module is used to identify the Pods scheduled to the worker nodes in order to determine the target Pods on the worker nodes, wherein the target Pods are the Pods that need to be managed for lifecycle extension. The behavior suppression module is used to suppress the native operation behavior of the Kubelet when the Kubelet deployed on the worker node performs lifecycle management on the target Pod; The extended management module is used to execute lifecycle management operations corresponding to the received lifecycle management instructions for the target Pod, and record the status information of the target Pod. The lifecycle management operations include one or any combination of startup, shutdown, and restart operations based on the original root file system of the target Pod, and the creation and destruction operations of the target Pod are executed by the Kubelet.

9. An electronic device, characterized in that, include: A processor, a storage device comprising at least one storage unit, and A communication bus that establishes a communication connection between the processor and the storage device; The processor is used to execute one or more programs stored in the storage device to implement the method of extending the Pod lifecycle as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable medium stores computer program instructions that, when read and executed by a processor, perform the method for extending the Pod lifecycle as described in any one of claims 1 to 7.

Images