CN116566802A - 资源回收方法及装置、存储介质及电子设备 - Google Patents

Abstract

本公开提供了一种资源回收方法及装置、存储介质及电子设备，涉及新兴信息技术技术领域。该方法包括，获取队列中Node节点的Pod信息，判断Node节点是否与Master端口失联；当Node节点与Master端口失联，将Node节点停止Kubelet服务；读取队列中的Pod，根据预设方式对Pod进行资源回收，其中，预设方式包括，备份Pod、保留Pod和删除Pod。本公开在Node节点在失联后处于未准备好状态下，对Node内部Pod根据预设方式进行控制和处理，停止原先业务网络对外提供服务，使得资源回收合理，保障服务的正常运行。

Description

资源回收方法及装置、存储介质及电子设备

技术领域

本公开涉及新兴信息技术技术领域，尤其涉及一种资源回收方法及装置、存储介质及电子设备。

背景技术

随着网络功能虚拟化(Network Functions Virtualization，NFV)技术的不断成熟，电信网元向云上迁移的趋势明显，并且呈现云原生上云的趋势。Google推出的Kubernetes(K8s)集群作为开源的大规模容器编排引擎，已经逐步成为了容器云的行业规范，也被广泛应用于承载云原生网元。相较于互联网技术(Internet Technology，IT)应用系统，容器云在承载电信网元时，对组网能力和可靠性有着更高的要求，要求云底座支持多网络平面。现已有Multus等多网络平面的CNI插件，使得在K8sNode可以为容器提供同时通过多个网络平面进行通信的能力，但也对K8s可靠性管理机制带来影响，使得因管理网故障造成容器被迁移和删除后，业务网依旧对外提供服务，影响正常的服务提供。目前从K8s针对Node丢失的原生做法是限时驱逐，长时等待恢复。Node被驱逐后，原本在Node上Pod会在别的Node上启动同样镜像版本的Pod予以替换，此时若原Node恢复正常，Master(主节点)则会将后来新起的Pod删掉，重新使用原Node上的Pod。当Master失联，Node处于NotReady(非正常、未准备好)状态后，Kubelet不会主动去对Pod做控制的，导致资源持续占用。

现有技术中，K8s已经支持Multus等多网络平面的CNI插件，而Kubernetes现有判断Node失效判定机制仍然还是通过判定K8s的管理网络(主网络)是否连通为判定依据。当管理网络断开而业务网络还存在通信流量时，此时由于K8s本身的Node资源回收机制影响，Master在别处Node重启服务，而原先业务网络仍然对外提供服务，资源回收的不合理，造成服务混乱异常。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开提供一种资源回收方法及装置、存储介质及电子设备，至少在一定程度上克服由于相关技术中资源回收不合理的问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一个方面，提供了一种资源回收方法，包括：获取队列中Node节点的Pod信息，判断所述Node节点是否与Master端口失联；当所述Node节点与Master端口失联，将所述Node节点停止Kubelet服务；读取队列中的Pod，根据预设方式对所述Pod进行资源回收，其中，所述预设方式包括，备份Pod、保留Pod和删除Pod。

在一些实施例中，所述获取队列中Node节点的Pod信息，判断所述Node节点是否与Master端口失联包括：通过远程接口获取Node节点中Pod的当前事件状况和资源情况；将所述Pod的当前事件状况和资源情况写入队列；根据预设的方式，判断所述Node节点是否与Master端口失联。

在一些实施例中，在所述读取队列中的Pod，根据预设方式对所述Pod进行资源回收之后，所述方法还包括：当所述Node节点状态为正常状态，将备份的Pod重新加载回所述Node节点激活运行；重启Kubelet服务；重新获取队列中Node节点的Pod信息，判断所述Node节点是否与Master端口失联。

在一些实施例中，所述资源回收方法还包括：根据所述Pod的当前事件状况和资源情况，将满足预设条件的Pod信息记录在Cache缓存中；从Cache缓存中读回要处理的Pod信息并写入到预设队列中；读取预设队列中的Pod，根据预设方式对所述Pod进行资源回收。

在一些实施例中所述资源回收方法还包括：当所述Node节点与Master端口连接正常，重新通过远程接口获取Node节点中Pod的当前事件状况和资源情况。

在一些实施例中，所述备份Pod、保留Pod和删除Pod包括：将Pod转为快照存储；保留需要运行的Pod；删除无需保留的Pod。

在一些实施例中，在所述获取队列中Node节点的Pod信息，判断所述Node节点是否与Master端口失联之前，所述方法还包括：通过远程接口获取Master端的预设方式。

根据本公开的另一个方面，还提供了一种资源回收装置，包括：失联判断模块，用于获取队列中Node节点的Pod信息，判断所述Node节点是否与Master端口失联；服务停止模块，用于当所述Node节点与Master端口失联，将所述Node节点停止Kubelet服务；资源回收模块，用于读取队列中的Pod，根据预设方式对所述Pod进行资源回收，其中，所述预设方式包括，备份Pod、保留Pod和删除Pod。

根据本公开的另一个方面，还提供了一种电子设备，该电子设备包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一项所述的资源回收方法。

根据本公开的另一个方面，还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的资源回收方法。

根据本公开的另一个方面，还提供了一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现上述任意一项的资源回收方法。

本公开的实施例中提供的一种资源回收方法，包括：获取队列中Node节点的Pod信息，判断Node节点是否与Master端口失联；当Node节点与Master端口失联，将Node节点停止Kubelet服务；读取队列中的Pod，根据预设方式对Pod进行资源回收，其中，预设方式包括，备份Pod、保留Pod和删除Pod。本公开在Node节点在失联后处于未准备好状态下，对Node内部Pod根据预设方式进行控制和处理，停止原先业务网络对外提供服务，使得资源回收合理，保障服务的正常运行。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出本公开实施例中资源回收方法的示例性应用系统架构示意图；

图2示出本公开实施例中节点正常时的示例性应用系统架构运行状态示意图；

图3示出本公开实施例中节点异常时的示例性应用系统架构运行状态示意图；

图4示出本公开实施例中一种资源回收方法流程图；

图5示出本公开实施例中一种资源回收方法的一具体实例的流程图；

图6示出本公开实施例中一种资源回收方法的另一具体实例的流程图；

图7示出本公开实施例中一种资源回收方法的又一具体实例的流程图；

图8示出本公开实施例中应用于ERP的一种资源回收的流程图；

图9示出本公开实施例中一种资源回收装置示意图；

图10示出本公开实施例中一种计算机设备的结构框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

下面结合附图，对本公开实施例的具体实施方式进行详细说明。

图1示出了可以应用本公开实施例中资源回收方法的示例性应用系统架构示意图。如图1所示，该系统架构可以包括Master设备101、Node节点102、存储Storage103和缓存Cache104。

其中，Node节点还包括Handler模块112、Recorder模块122和Scanner模块132。

Handler模块，用于和Master的连通交互，与Recorder模块共同处理来自Exception和Event两个队列的事件。

Recorder模块，用于Cache缓存，与Handler模块共同处理来自Exception和Event两个队列的事件。

Scanner模块，用于统一采集数据，读取Event事件并记录在事件队列中。

Cache缓存，用于存储由Recorder过滤出来的记录条件及信息。

Storage，用于备份存储Pod镜像及快照，由Handler管理。

本领域技术人员可以知晓，图1中的Master设备101、Node节点102、存储Storage103和缓存Cache104的数量仅仅是示意性的，根据实际需要，可以具有任意数目的终端设备、网络和服务器。本公开实施例对此不作限定。

本公开的资源回收方法的示例性应用系统架构，用于Master与Node失联后，Pod的删除、备份和恢复，解决Node上资源持续占用问题。

图2示出了节点正常时的示例性应用系统架构运行状态示意图。

如图2所示，本图是节点正常(OnReady)时，系统的运行状态。系统支持定义CRD策略配置，如Node失联后是否保留、备份或者删除Pod资源等。如没有额外定义CRD，则按照Master和Pod预设的条件执行。系统将需要处理的Pod信息和数据记录在Cache缓存中，防止因Node重启丢失数据，导致Recorder同步失败的情况。

其中，Handler用于与Master交互，监视Master的连通状态，读取Master侧的预设条件、Pod的配额限制等。

Handler还用于读取节点Pod的实时性能指标，如Pod States等，并写入EventQueue(事件队列)。

Scanner与Kubelet交互，统一采集数据，读取Event事件并记录到Event Queue中。

Recorder用于从Event Queue中获取Event信息，同时获取系统专用的CRD(CustomResource Define，自定义资源)定义。

本公开在Node与Master正常互联的情况下，系统取得Controller-Manager中预设或自定义设置的驱逐等待时间，当网络断开后，并且Node超出驱逐等待时间，触发系统运行。

图3示出了节点异常时的示例性应用系统架构运行状态示意图。

如图3所示，本图是是节点处于非正常时(NotReady)，系统的运行状态。

首先，Node节点失联后，Handler按照Master预设好的驱逐时间进行计时，计时结束后进入系统操作。

其次，进入系统后，Handler和Recorder都会切换角色，Handler将停止Kubelet，并共同操作Except队列。

然后，Scanner改为从CAdvisor获取状态。Recoder将从Cache回读要处理的Pod信息以及策略，通过Except队列下发任务给Handler接收并逐个处理，也会通过Scanner更新Pod的最新状态。

接着，Handler持续监视主网口与Master的通信情况，并对Recoder下发的任务进行处理。

最后，Handler通过Interface对容器引擎进行操作，主要是调度容器引擎实现镜像备份，并将生成的镜像快照存储在Storage，防止因容器继续运行导致的逻辑混乱问题。在节点主网络恢复后，Handler通过Storage快照还原容器继续提供服务，最后重启Kubelet使Node恢复。

本公开能够按照定义的CRD策略或者预设策略对Node和Pod进行处理，并停止容器服务，避免多网络平面下，管理网络失效后业务网络扔对外提供服务的情况。

在上述系统架构下，本公开实施例中提供了一种资源回收方法，该方法可以由任意具备计算处理能力的电子设备执行。

图4示出本公开实施例中一种资源回收方法流程图，如图4所示，本公开实施例中提供的资源回收方法包括如下步骤：

S402，获取队列中Node节点的Pod信息，判断Node节点是否与Master端口失联。

需要说明的是，上述Node节点可以是可以是一个虚拟机或者物理机器，取决于所在的集群配置。上述Pod信息可以是Pod的当前事件状况和资源情况。上述Master端口可以是集群控制节点，在每个Kubernetes集群里都需要有一个Master来负责整个集群的管理和控制，基本上Kubernetes的所有控制命令都发给它，它负责具体的执行过程。

例如，Kubernetes通过将容器放入在节点(Node)上运行的Pod。每个节点包含运行Pods所需的服务，这些Pods由控制面负责管理。

S404，当Node节点与Master端口失联，将Node节点停止Kubelet服务。

需要说明的是，上述Kubelet可以是工作节点上的主要服务，定期从kube-Apiserver组件接收新的或修改的Pod规范，并确保Pod及其容器在期望规范下运行。同时该组件作为工作节点的监控组件，向kube-Apiserver汇报主机的运行状况。

S406，读取队列中的Pod，根据预设方式对Pod进行资源回收，其中，预设方式包括，备份Pod、保留Pod和删除Pod。

需要说明的是，上述Pod是Kubernetes资源调度的基本单元。

本公开在Node节点在失联后处于非正常状态下，对Node内部Pod根据预设方式进行控制和处理，停止原先业务网络对外提供服务，使得资源回收合理，保障服务的正常运行。

图5示出本公开实施例中一种资源回收方法的一具体实例的流程图。如图5所示，获取队列中Node节点的Pod信息，判断Node节点是否与Master端口失联还可以包括如下步骤：

S502，通过远程接口获取Node节点中Pod的当前事件状况和资源情况；

S504，将Pod的当前事件状况和资源情况写入队列；

S506，根据预设的方式，判断Node节点是否与Master端口失联。

需要说明的是，上述预设的方式包括以下任意一种：

通过Ping命令对Pod获取IP，判断Node节点是否与Master端口失联；

通过Master端口获取健康状态，判断Node节点是否与Master端口失联。

本公开提供的实施例，通过获取Node节点中Pod的当前事件状况和资源情况，能够准确判断与Master端口失联的Node节点，对失联的Node节点再根据预设方式进行控制和处理，能够保障服务的正常运行。

图6示出本公开实施例中一种资源回收方法的另一具体实例的流程图。如图6所示，在读取队列中的Pod，根据预设方式对Pod进行资源回收之后还可以包括如下步骤：

S602，当Node节点状态为正常状态，将备份的Pod重新加载回Node节点激活运行；

S604，重启Kubelet服务；

S606，重新获取队列中Node节点的Pod信息，判断Node节点是否与Master端口失联。

本公开提供的实施例，通过检测Node节点状态，在Node节点状态为正常状态，将备份的Pod重新加载回Node节点激活运行并重启Kubelet服务，能够解决Node上资源持续占用问题。

图7示出本公开实施例中一种资源回收方法的又一具体实例的流程图。如图7所示，上述资源回收的方法还可以包括如下步骤：

S702，根据Pod的当前事件状况和资源情况，将满足预设条件的Pod信息记录在Cache缓存中；

S704，从Cache缓存中读回要处理的Pod信息并写入到预设队列中；

S706，读取预设队列中的Pod，根据预设方式对Pod进行资源回收。

本公开提供的实施例，通过缓存Pod信息，实现多网络平面下，在主网络故障时，业务网络能够有序提供服务的能力。

在本公开的一个实例中，当Node节点与Master端口连接正常，重新通过远程接口获取Node节点中Pod的当前事件状况和资源情况。

本公开提供的实施例，在Node节点未失联时，不会改变对Pod的管理，继续检测Node节点，保障服务的正常运行。

在本公开的一个实例中，备份Pod、保留Pod和删除Pod包括：将Pod转为快照存储；保留需要运行的Pod；删除无需保留的Pod。

例如，Handler根据信息记录的策略方式对当前pod进行处理，包含将Pod转为快照存储到Storage、保留需要运行的Pod、删除无需保留的Pod至少三种策略。

在本公开的一个实例中，在根据预设条件，确定与Master失联的Node之前，上述资源回收方法还包括：通过远程接口获取Master端的预设方式。

例如，Handler通过Remote Api(远程接口)获取Pod的当前事件状况和资源情况。

图8示出本公开实施例中应用于ERP的一种资源回收的流程图。如图8所示，应用于ERP的一种资源回收方法包括如下步骤：

S801，ERP(Enterprise Resource Planning，企业资源计划)系统启用，Handler通过remote api获取Master端的预置默认条件(相当于上述预设方式)；

S802，Handler通过Remote Api获取Pod的当前Event状况(相当于上述事件状况)和资源情况；

S803，将更新的Event信息写入Event Queue队列；

S804，判Node节点是否正常，若是，跳转S802，若否，跳转S805；

S805，Handler检测到链路断开，停止Kubelet并通知Recorder模块；

S806，Handler读取Except队列(消息队列)中需要处理的Pod信息；

S807，将需要处理的Pod信息写入Event Queue队列；

S808，Handler根据信息记录的策略方式对当前pod进行处理，包含将Pod转为快照存储到storage、保留需要运行的Pod、删除无需保留的Pod至少三种策略；

S809、判断节点是否恢复OnReady状态，若是，跳转S810，若否，跳转S806；

S810、将存储在Storage中的Pod快照重新加载回Node并激活运行；

S811、(角色切换)Handler重启Kubelet，并切换回对event queue的读写，同时通知Recorder进行相应的角色切换，并跳转S802；

S812，与S801同步进行，Recorder通过Scanner取得当前Node节点下的各个Pod运行状态及情况；

S813，读取Event Queue队列中的Event事件及信息；

S814，根据S803和S813获取的Event事件及信息，更新Event Queue队列信息；

S815，Recorder结合Event中的状态及条件，将符合情况的Pod信息记录在Cache缓存中；

S816，判Node节点是否正常，若是，跳转S812，若否，跳转S818；

S817，Cache缓存保存Pod信息；

S818，(角色切换)Recorder从Cache缓存中读回要处理的Pod信息并写入到Except队列中，跳转S807。

本公开通过设计一套Exception Recovery Policy系统，当Node节点在失联后处于NotReady状态下，对Node内部pod进行策略性的控制和处理。鉴于Node与Master失联是有时效性的，在正常与Master互联的情况下，ERP系统会取得Controller-Manager中预设或自定义设置的驱逐等待时间，当网络断开后，直到Node超出驱逐等待时间后，触发ERP系统。

本公开能够应用于云网融合场景下，网元云原生后涉及多网络平面时的集群管理，提高节点资源利用率，ERP系统负责Master与Node失联后，Pod的删除、备份和恢复，解决Node上资源持续占用问题。解决Pod使用多网络平面时，由于K8s本身的Node资源回收机制影响，造成Master在别处Node重启服务，而原先业务网络仍然对外提供服务，存在服务混乱异常的问题。

基于同一发明构思，本公开实施例中还提供了一种资源回收装置，如下面的实施例所述。由于该装置实施例解决问题的原理与上述方法实施例相似，因此该装置实施例的实施可以参见上述方法实施例的实施，重复之处不再赘述。

图9示出本公开实施例中一种资源回收装置示意图，如图9所示，该装置包括：失联判断模块91，服务停止模块92，资源回收模块93、服务重启模块94和预设方式获取模块95。

其中，失联判断模块91，用于获取队列中Node节点的Pod信息，判断Node节点是否与Master端口失联。

服务停止模块92，用于当Node节点与Master端口失联，将Node节点停止Kubelet服务。

资源回收模块93，用于读取队列中的Pod，根据预设方式对Pod进行资源回收，其中，预设方式包括，备份Pod、保留Pod和删除Pod。

在本公开的一个实例中，上述失联判断模块91具体用于：将Pod的当前事件状况和资源情况写入队列；根据预设的方式，判断Node节点是否与Master端口失联。

在本公开的一个实例中，上述资源回收装置还包括服务重启模块94：用于当Node节点状态为OnReady，将备份的Pod重新加载回Node节点激活运行；重启Kubelet服务；重新获取队列中Node节点的Pod信息，判断Node节点是否与Master端口失联。

在本公开的一个实例中，上述资源回收模块93具体用于：根据Pod的当前事件状况和资源情况，将满足预设条件的Pod信息记录在Cache缓存中；从Cache缓存中读回要处理的Pod信息并写入到预设队列中；读取预设队列中的Pod，根据预设方式对Pod进行资源回收。

在本公开的一个实例中，上述服务重启模块94还用于：当Node节点与Master端口连接正常，重新通过远程接口获取Node节点中Pod的当前事件状况和资源情况。

在本公开的一个实例中，上述资源回收模块93中备份Pod、保留Pod和删除Pod包括：将Pod转为快照存储；保留需要运行的Pod；删除无需保留的Pod。

在本公开的一个实例中，上述资源回收装置还包括预设方式获取模块95：用于通过远程接口获取Master端的预设方式。

此处需要说明的是，上述失联判断模块91、服务停止模块92和资源回收模块93对应于方法实施例中的S402～S406，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述方法实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以在诸如一组计算机可执行指令的计算机系统中执行。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

下面参照图10来描述根据本公开的这种实施方式的电子设备1000。图10显示的电子设备1000仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图10所示，电子设备1000以通用计算设备的形式表现。电子设备1000的组件可以包括但不限于：上述至少一个处理单元1010、上述至少一个存储单元1020、连接不同系统组件(包括存储单元1020和处理单元1010)的总线1030。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元1010执行，使得所述处理单元1010执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。

例如，所述处理单元1010可以执行上述方法实施例的如下步骤：获取队列中Node节点的Pod信息，判断Node节点是否与Master端口失联；

当Node节点与Master端口失联，将Node节点停止Kubelet服务；

读取队列中的Pod，根据预设方式对Pod进行资源回收，其中，预设方式包括，备份Pod、保留Pod和删除Pod。

例如，所述处理单元1010可以执行上述方法实施例的如下步骤：

通过远程接口获取Node节点中Pod的当前事件状况和资源情况；

将Pod的当前事件状况和资源情况写入队列；

根据预设的方式，判断Node节点是否与Master端口失联。

例如，所述处理单元1010可以执行上述方法实施例的如下步骤：

当Node节点状态为OnReady，将备份的Pod重新加载回Node节点激活运行；

重启Kubelet服务；

重新获取队列中Node节点的Pod信息，判断Node节点是否与Master端口失联。

例如，所述处理单元1010可以执行上述方法实施例的如下步骤：

根据Pod的当前事件状况和资源情况，将满足预设条件的Pod信息记录在Cache缓存中；

从Cache缓存中读回要处理的Pod信息并写入到预设队列中；

读取预设队列中的Pod，根据预设方式对Pod进行资源回收。

例如，所述处理单元1010可以执行上述方法实施例的如下步骤：

当Node节点与Master端口连接正常，重新通过远程接口获取Node节点中Pod的当前事件状况和资源情况。

例如，所述处理单元1010可以执行上述方法实施例的如下步骤：

将Pod转为快照存储；

保留需要运行的Pod；

删除无需保留的Pod。

例如，所述处理单元1010可以执行上述方法实施例的如下步骤：

通过远程接口获取Master端的预设方式。

存储单元1020可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)10201和/或高速缓存存储单元10202，还可以进一步包括只读存储单元(ROM)10203。

存储单元1020还可以包括具有一组(至少一个)程序模块10205的程序/实用工具10204，这样的程序模块10205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线1030可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备1000也可以与一个或多个外部设备1040(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备1000交互的设备通信，和/或与使得该电子设备1000能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1050进行。并且，电子设备1000还可以通过网络适配器1060与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器1060通过总线1030与电子设备1000的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1000使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机程序产品，该计算机程序产品包括：计算机程序，所述计算机程序被处理器执行时实现上述资源回收方法。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质可以是可读信号介质或者可读存储介质。其上存储有能够实现本公开上述方法的程序产品。在一些可能的实施方式中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。

本公开中的计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

在本公开中，计算机可读存储介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可选地，计算机可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

在具体实施时，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

Claims (10)

1.一种资源回收方法，其特征在于，包括：

获取队列中Node节点的Pod信息，判断所述Node节点是否与Master端口失联；

当所述Node节点与Master端口失联，将所述Node节点停止Kubelet服务；

读取队列中的Pod，根据预设方式对所述Pod进行资源回收，其中，所述预设方式包括，备份Pod、保留Pod和删除Pod。

2.根据权利要求1所述的资源回收方法，其特征在于，所述获取队列中Node节点的Pod信息，判断所述Node节点是否与Master端口失联包括：

通过远程接口获取Node节点中Pod的当前事件状况和资源情况；

将所述Pod的当前事件状况和资源情况写入队列；

根据预设的方式，判断所述Node节点是否与Master端口失联。

3.根据权利要求1或2所述的资源回收方法，其特征在于，在所述读取队列中的Pod，根据预设方式对所述Pod进行资源回收之后，所述方法还包括：

当所述Node节点状态为正常状态，将备份的Pod重新加载回所述Node节点激活运行；

重启Kubelet服务；

重新获取队列中Node节点的Pod信息，判断所述Node节点是否与Master端口失联。

4.根据权利要求2所述的资源回收方法，其特征在于，所述方法还包括：

根据所述Pod的当前事件状况和资源情况，将满足预设条件的Pod信息记录在Cache缓存中；

从Cache缓存中读回要处理的Pod信息并写入到预设队列中；

读取预设队列中的Pod，根据预设方式对所述Pod进行资源回收。

5.根据权利要求2所述的资源回收方法，其特征在于，所述方法还包括：

当所述Node节点与Master端口连接正常，重新通过远程接口获取Node节点中Pod的当前事件状况和资源情况。

6.根据权利要求1所述的资源回收方法，其特征在于，所述备份Pod、保留Pod和删除Pod包括：

将Pod转为快照存储；

保留需要运行的Pod；

删除无需保留的Pod。

7.根据权利要求1所述的资源回收方法，其特征在于，在所述获取队列中Node节点的Pod信息，判断所述Node节点是否与Master端口失联之前，所述方法还包括：

通过远程接口获取Master端的预设方式。

8.一种资源回收装置，其特征在于，包括：

失联判断模块，用于获取队列中Node节点的Pod信息，判断所述Node节点是否与Master端口失联；

服务停止模块，用于当所述Node节点与Master端口失联，将所述Node节点停止Kubelet服务；

资源回收模块，用于读取队列中的Pod，根据预设方式对所述Pod进行资源回收，其中，所述预设方式包括，备份Pod、保留Pod和删除Pod。

9.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1～7中任意一项所述的资源回收方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1～7中任意一项所述的资源回收方法。