Resource recycling method and device, storage medium and electronic equipment
Patent Information
- Application Number
- CN202310597652.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-05-24
- Publication Date
- 2026-10-13
- Estimated Expiration
- 2043-05-24
AI Technical Summary
[0005]本公开提供一种资源回收方法及装置、存储介质及电子设备,至少在一定程度上克服由于相关技术中资源回收不合理的问题
[0018]本公开的实施例中提供的一种资源回收方法,包括:获取队列中Node节点的Pod信息,判断Node节点是否与Master端口失联;当Node节点与Master端口失联,将Node节点停止Kubelet服务;读取队列中的Pod,根据预设方式对Pod进行资源回收,其中,预设方式包括,备份Pod、保留Pod和删除Pod。本公开在Node节点在失联后处于未准备好状态下,对Node内部Pod根据预设方式进行控制和处理,停止原先业务网络对外提供服务,使得资源回收合理,保障服务的正常运行。
Smart Images

Figure CN116566802B_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of emerging information technology, and in particular to a resource recycling method and apparatus, storage medium and electronic device. Background Technology
[0002] With the continuous maturation of Network Functions Virtualization (NFV) technology, the migration of telecommunications network elements to the cloud is evident, exhibiting a trend towards cloud-native cloud adoption. Google's Kubernetes (K8s) cluster, as an open-source large-scale container orchestration engine, has gradually become the industry standard for container clouds and is widely used to support cloud-native network elements. Compared to Internet Technology (IT) application systems, container clouds have higher requirements for networking capabilities and reliability when supporting telecommunications network elements, requiring the cloud infrastructure to support multiple network planes. Multi-network plane CNI plugins such as Multus are now available, enabling K8s nodes to provide containers with the ability to communicate simultaneously through multiple network planes. However, this also impacts the K8s reliability management mechanism, meaning that even if a container is migrated or deleted due to a management network failure, the service network may still continue to provide services, affecting normal service delivery. Currently, the native K8s approach to node loss is timed eviction followed by a long recovery wait. When a Node is evicted, the Pods that were originally on that Node will be replaced by Pods with the same image version started on other Nodes. If the original Node recovers, the Master will delete the newly started Pods and reuse the Pods from the original Node. When the Master is disconnected and the Node is in a NotReady state, Kubelet will not actively control the Pods, resulting in continuous resource consumption.
[0003] In existing technologies, Kubernetes already supports CNI plugins for multiple network planes, such as Multus. However, Kubernetes' current mechanism for determining Node failure still relies on the connectivity of the Kubernetes management network (master network) as the basis for judgment. When the management network is disconnected but the business network still has communication traffic, due to the impact of Kubernetes' own Node resource reclamation mechanism, the Master restarts services on a different Node, while the original business network continues to provide services. This unreasonable resource reclamation causes service chaos and anomalies.
[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention
[0005] This disclosure provides a resource recycling method and apparatus, storage medium and electronic device, which at least to some extent overcomes the problem of unreasonable resource recycling in related technologies.
[0006] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.
[0007] According to one aspect of this disclosure, a resource reclamation method is provided, comprising: obtaining Pod information of Node nodes in a queue, determining whether the Node node is disconnected from the Master port; when the Node node is disconnected from the Master port, stopping the Kubelet service of the Node node; reading Pods in the queue, and reclaiming resources from the Pods according to a preset method, wherein the preset method includes backing up the Pod, retaining the Pod, and deleting the Pod.
[0008] In some embodiments, obtaining the Pod information of the Node in the queue and determining whether the Node is disconnected from the Master port includes: obtaining the current event status and resource status of the Pod in the Node through a remote interface; writing the current event status and resource status of the Pod into the queue; and determining whether the Node is disconnected from the Master port according to a preset method.
[0009] In some embodiments, after the Pods in the read queue are reclaimed according to a preset method, the method further includes: when the Node node is in a normal state, reloading the backed-up Pods back to the Node node to activate and run; restarting the Kubelet service; re-acquiring the Pod information of the Node nodes in the queue, and determining whether the Node node has lost connection with the Master port.
[0010] In some embodiments, the resource reclamation method further includes: recording Pod information that meets preset conditions in a cache based on the current event status and resource status of the Pod; reading back the Pod information to be processed from the cache and writing it into a preset queue; reading the Pods in the preset queue and reclaiming resources from the Pods according to a preset method.
[0011] In some embodiments, the resource reclamation method further includes: when the Node node is normally connected to the Master port, re-obtaining the current event status and resource status of the Pod in the Node node through the remote interface.
[0012] In some embodiments, backing up a Pod, retaining a Pod, and deleting a Pod include: converting a Pod to snapshot storage; retaining Pods that need to be run; and deleting Pods that do not need to be retained.
[0013] In some embodiments, before obtaining the Pod information of the Node in the queue and determining whether the Node is disconnected from the Master port, the method further includes: obtaining a preset method of the Master through a remote interface.
[0014] According to another aspect of this disclosure, a resource reclamation device is also provided, comprising: a disconnection judgment module, used to obtain Pod information of Node nodes in a queue and determine whether the Node node is disconnected from the Master port; a service stop module, used to stop the Kubelet service of the Node node when the Node node is disconnected from the Master port; and a resource reclamation module, used to read Pods in the queue and reclaim resources from the Pods according to a preset method, wherein the preset method includes backing up the Pod, keeping the Pod, and deleting the Pod.
[0015] According to another aspect of this disclosure, an electronic device is also provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the resource recycling method described in any of the preceding claims by executing the executable instructions.
[0016] According to another aspect of this disclosure, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the resource reclamation method described in any of the preceding claims.
[0017] According to another aspect of this disclosure, a computer program product is also provided, including a computer program that, when executed by a processor, implements the resource recycling method of any of the above.
[0018] An embodiment of this disclosure provides a resource reclamation method, comprising: obtaining Pod information of Node nodes in a queue, determining whether the Node node has lost connection with the Master port; when the Node node loses connection with the Master port, stopping the Kubelet service of the Node node; reading the Pods in the queue, and reclaiming resources from the Pods according to a preset method, wherein the preset method includes backing up the Pod, retaining the Pod, and deleting the Pod. This disclosure controls and processes the Pods within the Node according to a preset method when the Node node is in an unprepared state after losing connection, stopping the original business network from providing services externally, thus ensuring reasonable resource reclamation and the normal operation of the service.
[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description
[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.
[0021] Figure 1 This diagram illustrates an exemplary application system architecture for the resource recycling method in this disclosure.
[0022] Figure 2 This diagram illustrates the operational status of an exemplary application system architecture when nodes are functioning normally, as shown in this embodiment of the disclosure.
[0023] Figure 3 This diagram illustrates the operational status of an exemplary application system architecture when a node malfunctions, as shown in this disclosure.
[0024] Figure 4 This diagram illustrates a flowchart of a resource recycling method according to an embodiment of the present disclosure;
[0025] Figure 5 A flowchart illustrating a specific example of a resource recycling method according to an embodiment of this disclosure is shown.
[0026] Figure 6 A flowchart illustrating another specific example of a resource recycling method according to an embodiment of this disclosure;
[0027] Figure 7 A flowchart illustrating yet another specific example of a resource recycling method according to an embodiment of this disclosure;
[0028] Figure 8 This invention discloses a flowchart illustrating a resource recycling method applied to an ERP system in an embodiment of the present disclosure.
[0029] Figure 9 This diagram illustrates a resource recycling device according to an embodiment of the present disclosure;
[0030] Figure 10 A structural block diagram of a computer device according to an embodiment of the present disclosure is shown. Detailed Implementation
[0031] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that this disclosure will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0032] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.
[0033] The specific implementation methods of the embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.
[0034] Figure 1 A schematic diagram of an exemplary application system architecture to which the resource recycling method of the embodiments of this disclosure can be applied is shown. For example... Figure 1 As shown, the system architecture may include a Master device 101, a Node node 102, Storage 103, and a Cache 104.
[0035] The Node module also includes a Handler module 112, a Recorder module 122, and a Scanner module 132.
[0036] The Handler module is used to communicate and interact with the Master, and together with the Recorder module, it handles events from the Exception and Event queues.
[0037] The Recorder module is used for caching and works with the Handler module to handle events from the Exception and Event queues.
[0038] The Scanner module is used to collect data uniformly, read Events, and record them in the event queue.
[0039] The cache is used to store the record conditions and information filtered by the recorder.
[0040] Storage is used to back up storage Pod images and snapshots, and is managed by Handler.
[0041] Those skilled in the art will know that Figure 1 The number of Master device 101, Node node 102, Storage 103, and Cache 104 in the diagram is merely illustrative; any number of terminal devices, networks, and servers can be included depending on actual needs. This disclosure does not limit the scope of the embodiments.
[0042] The exemplary application system architecture of the resource reclamation method disclosed herein is used for the deletion, backup, and recovery of Pods after the Master and Node lose connection, thereby resolving the problem of continuous resource occupation on the Node.
[0043] Figure 2 This diagram illustrates the operational status of an exemplary application system architecture when the nodes are functioning normally.
[0044] like Figure 2 As shown in the diagram, this represents the system's operational status when a node is normal (OnReady). The system supports defining CRD (Continuous Decision Registry) policy configurations, such as whether to retain, back up, or delete Pod resources after a node fails. If no additional CRD is defined, the system executes according to the preset conditions of the Master and Pods. The system records the Pod information and data that need to be processed in the cache to prevent data loss due to node restarts, which could lead to Recorder synchronization failures.
[0045] The Handler is used to interact with the Master, monitor the Master's connectivity status, and read the Master's preset conditions and Pod quota limits.
[0046] The Handler is also used to read real-time performance metrics of the Pod node, such as Pod States, and write them to the EventQueue.
[0047] The Scanner interacts with the Kubelet to collect data in a unified manner, read Events, and record them in the Event Queue.
[0048] The Recorder is used to retrieve Event information from the Event Queue, and also to retrieve the system-specific CRD (Custom Resource Define).
[0049] Under normal interconnection between the Node and the Master, the system obtains the eviction waiting time set by the preset or custom settings in the Controller-Manager. When the network is disconnected and the Node exceeds the eviction waiting time, the system is triggered to run.
[0050] Figure 3This diagram illustrates the operational status of an exemplary application system architecture when a node malfunctions.
[0051] like Figure 3 As shown in the figure, this diagram illustrates the system's operating state when a node is in an abnormal (NotReady) state.
[0052] First, after a Node becomes disconnected, the Handler starts timing according to the eviction time preset by the Master, and then enters system operations after the timing is completed.
[0053] Secondly, after entering the system, both the Handler and Recorder will switch roles. The Handler will stop the Kubelet and work together to operate the Except queue.
[0054] Then, the Scanner switches to obtaining the state from CAdvisor. The Recoder reads back the Pod information and policies to be processed from the Cache, sends tasks to the Handler via the Except queue for reception and processing, and also updates the latest Pod state via the Scanner.
[0055] Next, the Handler continuously monitors the communication between the main network interface and the Master, and processes the tasks issued by the Recoder.
[0056] Finally, the Handler operates on the container engine through the Interface, primarily scheduling the container engine to perform image backups and storing the generated image snapshots in Storage to prevent logical inconsistencies caused by the continued operation of containers. After the node's main network recovers, the Handler restores the containers using the Storage snapshots to continue providing services, and finally restarts the Kubelet to restore the Node.
[0057] This disclosure can process Nodes and Pods according to the defined CRD policy or preset policy, and stop container services, thus avoiding the situation where the business network continues to provide services after the management network fails in a multi-network plane environment.
[0058] Under the above system architecture, this disclosure provides a resource recycling method that can be executed by any electronic device with computing power.
[0059] Figure 4 This invention discloses a flowchart of a resource recycling method according to an embodiment of the present invention, as shown below. Figure 4 As shown, the resource recycling method provided in this embodiment includes the following steps:
[0060] S402: Obtain Pod information of Node nodes in the queue and determine whether the Node node has lost connection with the Master port.
[0061] It should be noted that the aforementioned Node can be a virtual machine or a physical machine, depending on the cluster configuration. The aforementioned Pod information can be the current event status and resource status of the Pod. The aforementioned Master port can be the cluster control node. Every Kubernetes cluster needs a Master to be responsible for the management and control of the entire cluster. Basically, all Kubernetes control commands are sent to it, and it is responsible for the specific execution process.
[0062] For example, Kubernetes uses containers to run as Pods on nodes. Each node contains the services needed to run the Pods, which are managed by the control plane.
[0063] S404: When a Node loses connection with the Master port, the Kubelet service on the Node will be stopped.
[0064] It should be noted that the aforementioned Kubelet can be the main service on the worker node, periodically receiving new or modified Pod specifications from the kube-Apiserver component and ensuring that the Pod and its containers run under the expected specifications. Simultaneously, this component acts as a monitoring component for the worker node, reporting the host's operational status to the kube-Apiserver.
[0065] S406 reads the Pods in the queue and performs resource reclamation on the Pods according to preset methods, including backing up the Pod, keeping the Pod, and deleting the Pod.
[0066] It should be noted that the Pod mentioned above is the basic unit of Kubernetes resource scheduling.
[0067] This disclosure describes how to control and manage the Pods inside a Node in an abnormal state after it becomes disconnected, according to a preset method, to stop the original business network from providing services to the outside world, so as to make the resource reclamation reasonable and ensure the normal operation of the service.
[0068] Figure 5 A flowchart illustrating a specific example of a resource recycling method according to an embodiment of this disclosure is shown. For example... Figure 5 As shown, obtaining Pod information from Node nodes in the queue and determining whether a Node node has lost connection with the Master port can also include the following steps:
[0069] S502 obtains the current event status and resource status of Pods in the Node through a remote interface;
[0070] S504 writes the current event status and resource status of the Pod to the queue;
[0071] S506 determines whether a Node has lost connection with the Master port according to a preset method.
[0072] It should be noted that the above preset methods include any of the following:
[0073] Use the Ping command to obtain the IP address of the Pod and determine whether the Node is disconnected from the Master port.
[0074] The health status is obtained through the Master port to determine whether the Node has lost connection with the Master port.
[0075] The embodiments provided in this disclosure can accurately identify Nodes that are disconnected from the Master port by obtaining the current event status and resource status of Pods in Nodes, and then control and process the disconnected Nodes according to a preset method to ensure the normal operation of the service.
[0076] Figure 6 A flowchart illustrating another specific example of a resource recycling method according to an embodiment of this disclosure is shown. For example... Figure 6 As shown, after reading the Pods in the queue and reclaiming their resources according to a preset method, the following steps may also be included:
[0077] S602, when the Node is in a normal state, reload the backed-up Pod back to the Node and activate it to run;
[0078] S604, Restart the Kubelet service;
[0079] S606: Retrieve Pod information from the Node nodes in the queue and determine if the Node nodes have lost connection with the Master port.
[0080] The embodiments provided in this disclosure can solve the problem of continuous resource occupation on the Node by detecting the Node status, reloading the backed-up Pod back to the Node to activate and run it when the Node status is normal, and restarting the Kubelet service.
[0081] Figure 7 A flowchart illustrating yet another specific example of a resource recycling method according to an embodiment of this disclosure is shown. For example... Figure 7 As shown, the above-mentioned resource recycling method may further include the following steps:
[0082] S702 records Pod information that meets preset conditions in the Cache based on the current event status and resource status of the Pod;
[0083] S704 reads the Pod information to be processed from the cache and writes it to a preset queue;
[0084] S706 reads Pods from the preset queue and performs resource reclamation on the Pods according to the preset method.
[0085] The embodiments provided in this disclosure enable the service network to provide services in an orderly manner when the main network fails, by caching Pod information under multiple network planes.
[0086] In one instance of this disclosure, when the Node node is connected to the Master port normally, the current event status and resource status of the Pod in the Node node are retrieved again through the remote interface.
[0087] The embodiments provided in this disclosure do not change the management of Pods when the Node node is not lost, and continue to detect the Node node to ensure the normal operation of the service.
[0088] In one instance of this disclosure, backing up a Pod, retaining a Pod, and deleting a Pod include: converting a Pod to snapshot storage; retaining Pods that need to be run; and deleting Pods that do not need to be retained.
[0089] For example, the Handler processes the current pod according to the information recording strategy, including at least three strategies: converting the pod into a snapshot and storing it in Storage, retaining the pods that need to run, and deleting the pods that do not need to be retained.
[0090] In one example of this disclosure, before determining the Node that has lost contact with the Master based on preset conditions, the above resource reclamation method further includes: obtaining the preset method of the Master through a remote interface.
[0091] For example, the Handler obtains the current event status and resource status of the Pod through the Remote API.
[0092] Figure 8 A flowchart illustrating a resource recycling method applied to an ERP system is shown in an embodiment of this disclosure. For example... Figure 8 As shown, a resource recycling method applied to ERP includes the following steps:
[0093] S801, the ERP (Enterprise Resource Planning) system is enabled. The Handler obtains the preset default conditions from the Master through the remote API (equivalent to the preset method mentioned above).
[0094] S802, the Handler obtains the current Event status (equivalent to the above event status) and resource status of the Pod through the Remote API;
[0095] S803, write the updated Event information to the Event Queue;
[0096] S804, determine if the Node is normal. If yes, jump to S802; otherwise, jump to S805.
[0097] S805, the Handler detects a link disconnection, stops the Kubelet, and notifies the Recorder module;
[0098] S806, the Handler reads the Pod information that needs to be processed from the Except queue (message queue);
[0099] S807 writes the Pod information that needs to be processed into the Event Queue;
[0100] S808, the Handler processes the current pod according to the information recording strategy, including at least three strategies: converting the pod into a snapshot and storing it in storage, retaining the pods that need to run, and deleting the pods that do not need to be retained;
[0101] S809. Determine whether the node has returned to the OnReady state. If yes, jump to S810; otherwise, jump to S806.
[0102] S810: Reload the Pod snapshot stored in Storage back into the Node and activate it to run;
[0103] S811, (Role Switching) The Handler restarts the Kubelet and switches back to reading and writing to the event queue. At the same time, it notifies the Recorder to perform the corresponding role switch and jumps to S802.
[0104] S812, which runs synchronously with S801, uses the Scanner to obtain the running status and conditions of each Pod under the current Node.
[0105] S813 reads Events and information from the Event Queue;
[0106] S814, based on the Event events and information obtained in S803 and S813, update the Event Queue information;
[0107] S815, Recorder combines the state and conditions in the Event to record the Pod information that meets the conditions in the Cache;
[0108] S816, determine if the Node is normal. If yes, jump to S812; otherwise, jump to S818.
[0109] S817 uses a cache to store Pod information;
[0110] S818 (Role Switching): The Recorder reads the Pod information to be processed from the Cache and writes it to the Except queue, then jumps to S807.
[0111] This disclosure presents an Exception Recovery Policy (ERP) system that strategically controls and handles pods within a Node when it becomes disconnected and enters a NotReady state. Given that the disconnection between a Node and its Master is time-limited, under normal interconnection conditions, the ERP system obtains the eviction waiting time preset or customized in the Controller-Manager. When the network connection is lost, the ERP system is triggered only after the Node exceeds the eviction waiting time.
[0112] This disclosure can be applied to cluster management in cloud-network convergence scenarios, particularly when multiple network planes are involved after the network element cloud-native architecture is implemented. It improves node resource utilization, and the ERP system handles the deletion, backup, and recovery of Pods after the Master and Nodes lose connection, resolving the issue of continuous resource occupation on Nodes. It also addresses the problem of service disruption and anomalies caused by the Kubernetes Node resource reclamation mechanism, which prevents the Master from restarting services on a different Node while the original business network continues to provide services when Pods use multiple network planes.
[0113] Based on the same inventive concept, this disclosure also provides a resource recycling device, as described in the following embodiments. Since the principle by which this device solves the problem is similar to that of the method embodiments described above, the implementation of this device embodiment can refer to the implementation of the method embodiments described above, and repeated details will not be repeated.
[0114] Figure 9 This diagram illustrates a resource recycling device according to an embodiment of the present disclosure, such as... Figure 9 As shown, the device includes: a disconnection judgment module 91, a service stop module 92, a resource reclamation module 93, a service restart module 94, and a preset method acquisition module 95.
[0115] Among them, the disconnection judgment module 91 is used to obtain the Pod information of the Node nodes in the queue and determine whether the Node nodes are disconnected from the Master port.
[0116] Service Stop Module 92 is used to stop the Kubelet service on a Node when it loses connection with the Master port.
[0117] The resource reclamation module 93 is used to read Pods in the queue and reclaim resources from the Pods according to preset methods, including backing up Pods, keeping Pods, and deleting Pods.
[0118] In one instance of this disclosure, the aforementioned disconnection judgment module 91 is specifically used to: write the current event status and resource status of the Pod into a queue; and determine whether the Node node has lost connection with the Master port according to a preset method.
[0119] In one example of this disclosure, the resource recycling device further includes a service restart module 94: used to reload the backed-up Pod back to the Node and activate it when the Node is in the OnReady state; restart the Kubelet service; re-acquire the Pod information of the Node in the queue and determine whether the Node is disconnected from the Master port.
[0120] In one example of this disclosure, the resource reclamation module 93 is specifically used to: record Pod information that meets preset conditions in the Cache based on the current event status and resource status of the Pod; read back the Pod information to be processed from the Cache and write it to the preset queue; read the Pods in the preset queue and reclaim resources from the Pods according to the preset method.
[0121] In one instance of this disclosure, the aforementioned service restart module 94 is also used to: when the Node node is connected to the Master port normally, re-obtain the current event status and resource status of the Pod in the Node node through the remote interface.
[0122] In one instance of this disclosure, the resource recycling module 93 described above includes backing up Pods, retaining Pods, and deleting Pods, which includes: converting Pods to snapshot storage; retaining Pods that need to be run; and deleting Pods that do not need to be retained.
[0123] In one example of this disclosure, the resource recycling device further includes a preset mode acquisition module 95: used to acquire the preset mode of the Master through a remote interface.
[0124] It should be noted that the aforementioned disconnection judgment module 91, service stop module 92, and resource reclamation module 93 correspond to S402 to S406 in the method embodiment. The examples and application scenarios implemented by these modules and their corresponding steps are the same, but they are not limited to the content disclosed in the above method embodiment. It should also be noted that these modules, as part of a device, can be executed in a computer system, such as a set of computer-executable instructions.
[0125] Those skilled in the art will understand that various aspects of this disclosure can be implemented as a system, method, or program product. Therefore, various aspects of this disclosure can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "system."
[0126] The following reference Figure 10 To describe an electronic device 1000 according to such an embodiment of the present disclosure. Figure 10 The electronic device 1000 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.
[0127] like Figure 10 As shown, the electronic device 1000 is manifested in the form of a general-purpose computing device. The components of the electronic device 1000 may include, but are not limited to: at least one processing unit 1010, at least one storage unit 1020, and a bus 1030 connecting different system components (including storage unit 1020 and processing unit 1010).
[0128] The storage unit stores program code that can be executed by the processing unit 1010, causing the processing unit 1010 to perform the steps described in the "Exemplary Methods" section above according to various exemplary embodiments of this disclosure.
[0129] For example, the processing unit 1010 can execute the following steps in the above method embodiment: obtain the Pod information of the Node in the queue, and determine whether the Node is disconnected from the Master port;
[0130] When a Node loses connection with the Master port, stop the Kubelet service on the Node.
[0131] Read the Pods in the queue and reclaim their resources according to preset methods, including backing up the Pod, keeping the Pod, and deleting the Pod.
[0132] For example, the processing unit 1010 can perform the following steps in the above method embodiment:
[0133] Obtain the current event status and resource status of Pods in the Node through a remote interface;
[0134] Write the current event status and resource status of the Pod to the queue;
[0135] Based on a preset method, determine whether the Node node has lost connection with the Master port.
[0136] For example, the processing unit 1010 can perform the following steps in the above method embodiment:
[0137] When the Node state is OnReady, the backed-up Pod will be reloaded back into the Node and activated to run.
[0138] Restart the Kubelet service;
[0139] Retrieve the Pod information of the Node nodes in the queue to determine if the Node nodes have lost connection with the Master port.
[0140] For example, the processing unit 1010 can perform the following steps in the above method embodiment:
[0141] Based on the current event status and resource status of the Pod, Pod information that meets the preset conditions is recorded in the Cache.
[0142] Read the Pod information to be processed from the cache and write it to the preset queue;
[0143] Read the Pods from the preset queue and reclaim their resources according to the preset method.
[0144] For example, the processing unit 1010 can perform the following steps in the above method embodiment:
[0145] Once the Node node is successfully connected to the Master port, it re-obtains the current event status and resource status of the Pods in the Node node through the remote interface.
[0146] For example, the processing unit 1010 can perform the following steps in the above method embodiment:
[0147] Convert the Pod to snapshot storage;
[0148] Retain the Pods that need to run;
[0149] Delete Pods that do not need to be kept.
[0150] For example, the processing unit 1010 can perform the following steps in the above method embodiment:
[0151] Obtain the default method from the Master through a remote interface.
[0152] Storage unit 1020 may include readable media in the form of volatile storage units, such as random access memory (RAM) 10201 and / or cache memory 10202, and may further include read-only memory (ROM) 10203.
[0153] Storage unit 1020 may also include a program / utility 10204 having a set (at least one) program module 10205, such program module 10205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.
[0154] Bus 1030 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the multiple bus structures.
[0155] Electronic device 1000 can also communicate with one or more external devices 1040 (e.g., keyboard, pointing device, Bluetooth device, etc.), one or more devices that enable a user to interact with electronic device 1000, and / or any device that enables electronic device 1000 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 1050. Furthermore, electronic device 1000 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 1060. As shown, network adapter 1060 communicates with other modules of electronic device 1000 via bus 1030. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 1000, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.
[0156] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.
[0157] In particular, according to embodiments of this disclosure, the process described above with reference to the flowchart can be implemented as a computer program product, which includes a computer program that, when executed by a processor, implements the resource reclamation method described above.
[0158] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, which may be a readable signal medium or a readable storage medium. A program product capable of implementing the methods described above is stored thereon. In some possible implementations, various aspects of this disclosure may also be implemented as a program product including program code, which, when run on a terminal device, causes the terminal device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure.
[0159] More specific examples of computer-readable storage media in this disclosure may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0160] In this disclosure, a computer-readable storage medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting a program for use by or in connection with an instruction execution system, apparatus, or device.
[0161] Optionally, the program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.
[0162] In practical implementation, program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages such as Java and C++, and conventional procedural programming languages such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).
[0163] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.
[0164] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.
[0165] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.
[0166] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.
Claims
1. A resource recycling method, characterized in that, include: When the Node node and the Master port are normally connected, the eviction waiting time is obtained. When the network is disconnected and the Node node exceeds the eviction waiting time, the system is triggered to run. The system performs resource reclamation, obtains the Pod information of the Node nodes in the queue, and determines whether the Node node has lost connection with the Master port. When the Node loses connection with the Master port, stop the Kubelet service on the Node; Read the Pods in the queue and reclaim resources from the Pods according to a preset method, wherein the preset method includes backing up the Pod, keeping the Pod, and deleting the Pod; When the Node is in a normal state, the backed-up Pod will be reloaded back to the Node and activated to run. Restart the Kubelet service; Retrieve the Pod information of the Node nodes in the queue and determine whether the Node nodes have lost connection with the Master port.
2. The resource recycling method according to claim 1, characterized in that, The step of obtaining the Pod information of the Node nodes in the queue and determining whether the Node nodes have lost connection with the Master port includes: Obtain the current event status and resource status of Pods in the Node through a remote interface; Write the current event status and resource status of the Pod to the queue; According to a preset method, it is determined whether the Node has lost connection with the Master port.
3. The resource recycling method according to claim 2, characterized in that, The method further includes: Based on the current event status and resource status of the Pod, the Pod information that meets the preset conditions is recorded in the Cache. Read the Pod information to be processed from the cache and write it to the preset queue; Read the Pods from the preset queue and reclaim resources from the Pods according to the preset method.
4. The resource recycling method according to claim 2, characterized in that, The method further includes: Once the Node is successfully connected to the Master port, it re-obtains the current event status and resource status of the Pods in the Node through the remote interface.
5. The resource recycling method according to claim 1, characterized in that, The backup Pod, retained Pod, and deleted Pod include: Convert the Pod to snapshot storage; Retain the Pods that need to run; Delete Pods that do not need to be kept.
6. The resource recycling method according to claim 1, characterized in that, Before obtaining the Pod information of the Node nodes in the queue and determining whether the Node node has lost connection with the Master port, the method further includes: Obtain the default method from the Master through a remote interface.
7. A resource recycling device, characterized in that, include: When the Node and Master ports are normally interconnected, the eviction waiting time is obtained. When the network is disconnected and the Node exceeds the eviction waiting time, the system is triggered to run and perform resource reclamation. The disconnection detection module is used to obtain the Pod information of the Node nodes in the queue and determine whether the Node node has lost connection with the Master port; The service stop module is used to stop the Kubelet service of the Node when the Node loses connection with the Master port; The resource reclamation module is used to read Pods in the queue and reclaim resources from the Pods according to a preset method, wherein the preset method includes backing up Pods, keeping Pods, and deleting Pods; The service restart module is used to reload the backed-up Pods back to the Node and activate them when the Node is in a normal state; restart the Kubelet service; retrieve the Pod information of the Node in the queue again; and determine whether the Node is disconnected from the Master port.
8. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the resource reclamation method according to any one of claims 1 to 6 by executing the executable instructions.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the resource recycling method according to any one of claims 1 to 6.
Citation Information
Patent Citations
Resource recovery method and device and computer readable storage medium
CN112214323A