CN110618853B - 一种僵尸容器的检测方法、装置及设备 - Google Patents

Abstract

本申请公开一种僵尸容器的检测方法、装置及设备，该方法包括：主Agent在确定任一Slave主机存在异常时，向该Slave主机配置的子Agent发送异常检测请求；子Agent在接收到异常检测请求时，检测该Slave主机中是否存在异常容器，并将得到的检测结果上报至主Agent；主Agent根据检测结果确定该Slave主机中存在异常容器后，向该Slave主机配置的子Agent发送僵尸容器检测请求；子Agent基于所述异常容器与对应的容器组的运行状态比对结果，和\或，所述异常容器返回响应的情况，确定所述异常容器是否为僵尸容器。本申请逐层实现对僵尸容器的检测，并基于异常容器与对应容器组的运行状态比对结果、异常容器返回响应的情况，准确确定出异常容器是否为僵尸容器。

Description

一种僵尸容器的检测方法、装置及设备

技术领域

本申请涉及数据处理领域，具体涉及一种僵尸容器的检测方法、装置及设备。

背景技术

在容器的运行过程中，可能由于内部进程、Docker(应用容器引擎)响应能力等因素造成容器无法正常工作也无法被删除，且在容器列表中仍显示为运行态，对于这种类型的容器通常被称为僵尸容器。由于僵尸容器的存在可能造成应用异常难以修复，严重时可能会影响整个Docker环境的正常运行，因此需要对其进行及时的检测及处理。

目前，对于容器状态的检测是利用health check脚本完成的，具体的，healthcheck脚本通过获取***中用于表示容器状态的参数，来确定容器是否正常运行。但是，仅通过获取参数的方式是不能确定僵尸容器的，因为僵尸容器的参数可能仍显示为运行态，但事实上它已经无法正常工作且无法被删除，也就是说，僵尸容器的参数不能准确反映自身的状态。

因此，目前亟需能够准确检测僵尸容器的方式，以避免僵尸容器的存在造成应用异常难以修复，以及影响整个Docker环境的正常运行的状况发生。

发明内容

有鉴于此，本申请提供了一种僵尸容器的检测方法、装置及设备，能够准确检测僵尸容器。

第一方面，为实现上述发明目的，本申请提供了一种僵尸容器的检测方法，所述方法应用于容器集群管理***，所述容器集群管理***包括雇主主机和从主机，所述雇主主机配置有主代理，所述从主机配置有子代理，所述方法包括：

所述主代理在确定任一从主机存在异常时，向存在异常的所述从主机配置的子代理发送异常检测请求；

所述子代理在接收到所述异常检测请求时，检测存在异常的所述从主机中是否存在异常容器，并将检测结果上报至所述主代理；

所述主代理根据所述检测结果确定存在异常的所述从主机中存在异常容器后，向存在异常的所述从主机配置的子代理发送指明所述异常容器的僵尸容器检测请求；

所述子代理基于所述异常容器与对应的容器组的运行状态比对结果，和\或，所述异常容器返回响应的情况，确定所述异常容器是否为僵尸容器。

一种可选的实施方式中，所述检测存在异常的从主机中是否存在异常容器，包括：

确定存在异常的从主机的应用容器引擎中运行的各个容器组分别对应的容器；将所述各个容器组分别对应的容器与预设容器列表中存储的各个容器组分别对应的容器进行比对，以确定所述存在异常的从主机中是否存在异常容器；其中，所述异常容器为所述应用容器引擎中与所述预设容器列表比对不一致的容器；

和\或，

获取预设进程资源占用列表中占用资源量大的前N项进程；确定所述前N项进程占用的***资源是否存在异常，以确定所述存在异常的从主机中是否存在异常容器；其中，所述异常容器为占用的***资源存在异常的进程对应的容器。

一种可选的实施方式中，所述获取预设进程资源占用列表中占用资源量大的前N项进程之前，还包括：

检测所述从主机的应用容器引擎是否存在运行异常；

如果确定所述从主机的应用容器引擎存在运行异常，则触发所述获取预设进程资源占用列表中占用资源量大的前N项进程步骤的执行。

一种可选的实施方式中，所述检测所述从主机的应用容器引擎是否存在运行异常，包括：

向所述从主机的应用容器引擎发送预设***命令，以获得所述应用容器引擎的响应时间；

通过确定所述响应时间是否异常，确定所述应用容器引擎是否存在运行异常。

一种可选的实施方式中，所述子代理基于所述异常容器与对应的容器组的运行状态比对结果，和\或，所述异常容器返回响应的情况，确定所述异常容器是否为僵尸容器，包括：

所述子代理检测所述异常容器对应的容器组的运行状态与所述异常容器的运行状态是否一致，以确定所述异常容器是否为僵尸容器；其中，所述僵尸容器为与对应的容器组的运行状态不一致的异常容器；

或者，

所述子代理向所述异常容器发送预设次数的请求，以确定所述异常容器是否为僵尸容器；其中，所述僵尸容器为未返回响应的异常容器；

或者，

所述子代理检测所述异常容器对应的容器组的运行状态与所述异常容器的运行状态是否一致；如果一致，则向所述异常容器发送预设次数的请求，以确定所述异常容器是否为僵尸容器；其中，所述僵尸容器为未返回响应的异常容器。

一种可选的实施方式中，所述方法还包括：

如果所述子代理确定所述异常容器为僵尸容器，则将所述僵尸容器返回至所述主代理；

所述主代理删除所述僵尸容器对应的容器组；或者，所述主代理向所述子代理发送容器删除命令；其中，所述容器删除命令用于指示所述子代理请求应用容器引擎删除所述僵尸容器，或者，用于指示所述子代理删除所述僵尸容器对应的进程。

一种可选的实施方式中，所述主代理删除所述僵尸容器对应的容器组之后，所述方法还包括：

如果所述主代理未成功删除所述容器组，则所述主代理向所述子代理发送第一容器删除命令，以使所述子代理请求应用容器引擎删除所述僵尸容器；

或者，所述主代理向所述子代理发送容器删除命令之后，还包括：

如果所述子代理未成功请求应用容器引擎删除所述僵尸容器，则所述主代理向所述子代理发送第二容器删除命令，以使所述子代理删除所述僵尸容器对应的进程。

第二方面，本申请还提供了一种僵尸容器的检测装置，所述装置应用于容器集群管理***，所述容器集群管理***包括雇主主机和从主机，所述雇主主机配置有主代理，所述从主机配置有子代理，所述装置包括主代理和子代理；所述主代理包括第一发送模块和第二发送模块；所述子代理包括第一检测模块、上报模块和第二检测模块；

所述第一发送模块，用于在确定任一Slave主机存在异常时，向存在异常的所述Slave主机配置的子Agent发送异常检测请求；

所述第一检测模块，用于在接收到所述异常检测请求时，检测存在异常的所述从主机中是否存在异常容器；

所述上报模块，用于将所述第一检测模块得检测结果上报至所述主代理；

所述第二发送模块，用于根据所述检测结果确定存在异常的所述Slave主机中存在异常容器后，向存在异常所述Slave主机配置的子Agent发送指明所述异常容器的僵尸容器检测请求；

所述第二检测模块，用于基于所述异常容器与对应的容器组的运行状态比对结果，和\或，所述异常容器返回响应的情况，确定所述异常容器是否为僵尸容器。

一种可选的实施方式中，所述第一检测模块，包括：

第一检测子模块，用于确定存在异常的从主机的应用容器引擎中运行的各个容器组分别对应的容器；将所述各个容器组分别对应的容器与预设容器列表中存储的各个容器组分别对应的容器进行比对，以确定所述存在异常的从主机中是否存在异常容器；其中，所述异常容器为所述应用容器引擎中与所述预设容器列表比对不一致的容器；

和\或，

第二检测子模块，用于获取预设进程资源占用列表中占用资源量大的前N项进程；确定所述前N项进程占用的***资源是否存在异常，以确定所述存在异常的从主机中是否存在异常容器；其中，所述异常容器为占用的***资源存在异常的进程对应的容器。

一种可选的实施方式中，所述装置还包括：

第三检测子模块，用于检测所述从主机的应用容器引擎是否存在运行异常；

触发子模块，用于在确定所述从主机的应用容器引擎存在运行异常，触发所述第二检测子模块。

一种可选的实施方式中，所述第三检测子模块，包括：

发送子模块，用于向所述从主机的应用容器引擎发送预设***命令，以获得所述应用容器引擎的响应时间；

确定子模块，用于通过确定所述响应时间是否异常，确定所述应用容器引擎是否存在运行异常。

一种可选的实施方式中，所述第二检测模块，包括：

第四检测子模块，用于检测所述异常容器对应的容器组的运行状态与所述异常容器的运行状态是否一致，以确定所述异常容器是否为僵尸容器；其中，所述僵尸容器为与对应的容器组的运行状态不一致的异常容器；

或者，

第五检测子模块，用于向所述异常容器发送预设次数的请求，以确定所述异常容器是否为僵尸容器；其中，所述僵尸容器为未返回响应的异常容器；

或者，

第六检测子模块，用于检测所述异常容器对应的容器组的运行状态与所述异常容器的运行状态是否一致；如果一致，则向所述异常容器发送预设次数的请求，以确定所述异常容器是否为僵尸容器；其中，所述僵尸容器为未返回响应的异常容器。

一种可选的实施方式中，所述装置还包括：

返回模块，用于在确定所述异常容器为僵尸容器，将所述僵尸容器返回至所述主代理；

第一删除模块，用于删除所述僵尸容器对应的容器组；或者，向所述子代理发送容器删除命令；其中，所述容器删除命令用于指示所述子代理请求应用容器引擎删除所述僵尸容器，或者，用于指示所述子代理删除所述僵尸容器对应的进程。

一种可选的实施方式中，所述装置还包括：

第二删除模块，用于在所述第一删除模块未成功删除所述容器组时，向所述子代理发送第一容器删除命令，以使所述子代理请求应用容器引擎删除所述僵尸容器；

或者，所述装置还包括：

第三删除模块，用于在所述第一删除模块未成功请求应用容器引擎删除所述僵尸容器时，向所述子代理发送第二容器删除命令，以使所述子代理删除所述僵尸容器对应的进程。

第三方面，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在终端设备上运行时，使得所述终端设备执行上述任一项所述的方法。

第四方面，本申请还提供了一种僵尸容器的检测设备，包括：存储器，处理器，及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时，实现上述任一项所述的方法。

本申请提供的僵尸容器检测方法中，容器集群管理***的雇主主机中的主代理在确定任一从主机存在异常时，向该从主机的子代理发送异常检测请求，以确定该存在异常的从主机中是否存在异常容器。如果存在异常容器，主代理向该存在异常的从主机的子代理发送僵尸容器检测请求，以进一步确定该异常容器是否为僵尸容器。本申请实施例通过先确定存在异常的从主机，然后进一步确定该存在异常的从主机上的异常容器，最终确定该异常容器是否为僵尸容器的方式，逐层实现对僵尸容器的检测。另外，本申请基于异常容器与对应容器组的运行状态比对结果、异常容器返回响应的情况，能够准确确定出异常容器是否为僵尸容器。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种僵尸容器的检测方法所应用的***架构示意图；

图2为本申请实施例提供的一种僵尸容器的检测方法的数据交互图；

图3为本申请实施例提供的另一种僵尸容器的检测方法的数据交互图；

图4为本申请实施例提供的一种僵尸容器的删除方法的数据交互图；

图5为本申请实施例提供的一种僵尸容器的检测装置的结构示意图；

图6为本申请实施例提供的一种僵尸容器的检测设备的结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

僵尸容器是指无法正常工作且无法被删除的容器，这种容器的存在可能造成应用异常难以修复，严重时可能影响整个应用容器引擎Docker环境的正常运行，因此对于僵尸容器需要及时处理。

本申请提供了一种僵尸容器的检测方法，在容器集群管理***的雇主Master主机上部署主代理Agent，从Slave主机上部署子Agent。主Agent在确定任一Slave主机存在异常时，向该Slave主机对应的子Agent发送异常检测请求，以使其检测是否存在异常容器，并将检测结果上报至主Agent。主Agent根据检测结果确定存在异常容器后，向其对应的子Agent发送指明所述异常容器的僵尸容器检测请求，以使该子Agent检测该异常容器是否为僵尸容器。另外，本申请基于异常容器与对应容器组的运行状态比对结果、异常容器返回响应的情况，能够准确确定出异常容器是否为僵尸容器，以便及时删除僵尸容器，降低僵尸容器的影响。

本申请在进行具体技术方案的介绍之前，首先对以下概念进行简单介绍，以便于对技术方案进行理解。

容器集群管理***，目前Kubernetes(简称k8s)***为主流的容器集群管理***，用于自动化部署、扩展和管理容器应用，提供了资源调度、部署管理、服务发现、扩容缩容、监控等一整套功能。

Docker，是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。

pod，可以称为容器组，是k8s的最小单元，容器包含在pod中，一个pod中有一个pause***容器和若干个业务容器，k8s不直接运行容器，而是将一个或多个容器封装到pod中。

本申请在进行具体技术方案的介绍之前，还需要介绍一下本申请提供的僵尸容器的检测方法所应用的***架构，参考图1，为本申请实施例提供的一种僵尸容器的检测方法所应用的***架构示意图，以Kubernetes(k8s)***为例，包括Master主机和Slave主机，Master主机配置有主Agent，Slave主机配置有子Agent，主Agent可以与各个子Agent进行数据通信。各个Slave主机中运行有应用容器引擎Docker，每个Docker中运行有若干pod，其中，每个pod中封装有一个***容器container以及一个或多个业务容器。主Agent可以对各个pod进行状态监控。

基于图1中的***架构，本申请实施例提供了一种僵尸容器的检测方法，参考图2，为本申请实施例提供的一种僵尸容器的检测方法的数据交互图，该方法应用于容器集群管理***，该容器集群管理***包括Master主机和Slave主机，Master主机配置有主Agent，Slave主机配置有子Agent，具体的，该方法包括：

S201：主Agent在确定任一Slave主机存在异常时，向存在异常的所述Slave主机配置的子Agent发送异常检测请求。

实际应用中，主Agent对各个Slave主机进行监控，以确定各个Slave主机是否存在异常。

一种可选的实施方式中，主Agent周期性的检测容器集群管理***中的各个Slave主机上的各个pod的运行状态，并在检测到任一pod运行异常时，确定该pod对应的Slave主机存在异常。

另一种可选的实施方式中，由于Master主机与各个Slave主机之间存在心跳连接，当主Agent检测到Master主机与任一Slave主机之间的心跳连接断开时，可以确定该Slave主机存在异常。

值得注意的是，本申请不限定用于确定存在异常的Slave主机的方式。

本申请实施例中，主Agent在确定存在异常的Slave主机后，向该Slave主机中的子Agent发送异常检测请求，其中，异常检测请求用于指示子Agent对Slave主机进行具体的异常状态检测。

S202：子Agent在接收到所述异常检测请求时，检测存在异常的所述Slave主机中是否存在异常容器，并将检测结果上报至所述主Agent。

本申请实施例中，Slave主机的子Agent在接收到来自主Agent发送的异常检测请求后，检测该Slave主机中是否存在异常容器。

一种实施方式中，首先，子Agent在接收到来自主Agent发送的异常检测请求后，向对应的Slave主机中的Docker发送请求，以获知该Docker中当前各个pod中分别运行的容器，得到各个pod与容器的对应关系。其次，子Agent获取预设容器列表中存储的各个pod与容器的对应关系，并将这两种对应关系进行比对。由于预设容器列表中存储的各个pod与容器的对应关系为预先配置的对应关系，正常运行的情况下，Docker中的各个pod对应的容器应该是符合预设容器列表中的配置信息，如果存在不一致的情况，则说明Docker中存在异常容器。具体的，将Docker中与预设容器列表中存储的pod与容器的对应关系不一致的对应关系中的容器确定为异常容器。

另一种实施方式中，子Agent在接收到来自主Agent发送的异常检测请求后，首先获取对应的Slave主机的预设进程资源占用列表中占用资源量大的前N项进程；其中，预设进程资源占用列表中用于存储各个进程的占用资源情况，通过将预设进程资源占用列表中的各个进程的资源占用情况进行排序，可以得到占用资源量大的前N项进程，其中，N为正整数，如10。其次，子Agent确定该前N项进程占用的***资源是否存在异常，具体的，可以将该前N项进程的占用资源情况与前一段时间的进行比对，如果明显比前一段时间的资源占用量大，则可以说明该进程当前占用的***资源存在异常。本申请实施例中，可以将存在异常的进程对应的容器确定为异常容器。

本申请实施例中，子Agent检测到对应Slave主机中存在异常容器后，得到的检测结果可以包括用于表示该Slave主机存在异常的信息，更进一步的，检测结果中还可以包括异常容器的标识等信息，用于指明具体存在异常的容器。

又一种实现方式中，Slave主机的子Agent在接收到来自主Agent发送的异常检测请求后，还可以检测该Slave主机的应用容器引擎Docker是否存在运行异常。具体的，子Agent在接收到所述异常检测请求时，可以向对应Slave主机的Docker发送预设***命令，以获得该Docker的响应时间；如果该响应时间异常，则可以确定该Docker存在运行异常。进一步的，如果确定该Slave主机的Docker存在运行异常，则可以获取预设进程资源占用列表中占用资源量大的前N项进程，确定前N项进程占用的***资源是否存在异常，以确定所述存在异常的从主机中是否存在异常容器；其中，所述异常容器为占用的***资源存在异常的进程对应的容器。

一种可选的实施方式中，子Agent获得Docker的响应时间后，与预先周期性获得的该Docker的响应时间进行比对，如果该响应时间明显较长，则可以说明该Docker当前存在运行异常。另一种可选的实施方式中，子Agent获得Docker的响应时间后，还可以将该响应时间与预设响应阈值进行比对，如果该响应时间大于该预设响应阈值，则说明该Docker当前存在运行异常。

值得注意的是，本申请不限定用于检测Slave主机中是否存在异常容器的其他方式。

另一种应用场景中，各个Slave主机的子Agent可以周期性的主动执行检测对应Slave主机中是否存在异常容器的步骤，并将得到的检测结果上报至主Agent，以便主Agent能够及时检测到各个Slave主机的异常。

S203：主Agent根据所述检测结果确定存在异常的Slave主机中存在异常容器后，向该存在异常的Slave主机配置的子Agent发送指明异常容器的僵尸容器检测请求。

本申请实施例中，主Agent在接收到来自子Agent的检测结果后，对检测结果进行解析后确定该存在异常的Slave主机中是否存在异常容器。如果主Agent确定该存在异常的Slave主机中存在异常容器后，向该存在异常的Slave主机的子Agent发送指明异常容器的僵尸容器检测请求，以指示该子Agent检测该异常容器是否为僵尸容器。具体的，该僵尸容器检测请求可以携带异常容器的标识。

S204：子Agent基于所述异常容器与对应的容器组的运行状态比对结果，和\或，所述异常容器返回响应的情况，确定所述异常容器是否为僵尸容器。

本申请实施例中，僵尸容器检测请求中指明了异常容器。因此，子Agent在接收到僵尸容器检测请求后，可以检测该异常容器是否为僵尸容器。

一种可选的实施方式中，子Agent在接收到指明异常容器的僵尸容器检测请求后，可以检测该异常容器对应的pod的运行状态与该异常容器本身的运行状态是否一致。具体的，子Agent可以通过***命令获得pod的运行状态以及异常容器的运行状态。如果确定该异常容器对应的pod的运行状态与该异常容器本身的运行状态不一致，则可以确定该异常容器为僵尸容器。

另一种可选的实施方式中，子Agent在接收到指明异常容器的僵尸容器检测请求后，可以向该异常容器发送预设次数的请求；如果该异常容器未返回响应，则可以确定该异常容器为僵尸容器。具体的，子Agent可以向该异常容器发送至少5次请求，如果该异常容器对于这5次请求均未返回响应，则可以确定该异常容器为僵尸容器。

又一种可选的实施方式中，为了尽量避免僵尸容器的漏检，子代理在检测异常容器对应的容器组的运行状态与所述异常容器的运行状态是否一致之后，还包括：如果子代理确定异常容器对应的容器组的运行状态与该异常容器的运行状态一致，则也不能直接说明该异常容器不是僵尸容器，需要进一步的对该异常容器进行检测。具体的，子代理向该异常容器发送预设次数的请求，以确定该异常容器是否为僵尸容器，如果该异常容器未返回响应，则可以说明该异常容器为僵尸容器；否则可以说明其不是僵尸容器，或者可以继续进行进一步的检测，在此本申请不作限制。

本申请实施例提供的僵尸容器检测方法中，容器集群管理***的雇主主机中的主代理在确定任一从主机存在异常时，向该从主机的子代理发送异常检测请求，以确定该存在异常的从主机中是否存在异常容器。如果存在异常容器，主代理向该存在异常的从主机的子代理发送僵尸容器检测请求，以进一步确定该异常容器是否为僵尸容器。本申请实施例通过先确定存在异常的从主机，然后进一步确定该存在异常的从主机上的异常容器，最终确定该异常容器是否为僵尸容器的方式，逐层实现对僵尸容器的检测。另外，本申请基于异常容器与对应容器组的运行状态比对结果、异常容器返回响应的情况，能够准确确定出异常容器是否为僵尸容器。

由于僵尸容器的存在可能造成应用异常难以修复，严重时可能影响整个Docker环境的正常运行，因此对于僵尸容器需要及时删除。基于此，本申请实施例还提供了一种僵尸容器的检测方法，在检测到僵尸容器后，能够对僵尸容器进行及时的删除，降低僵尸容器的影响。

参考图3，为本申请实施例提供的另一种僵尸容器的检测方法的数据交互图，在图2的S201-S204步骤的基础上，本申请实施例还包括步骤S301和S302，具体的：

S201：主Agent在确定任一Slave主机存在异常时，向存在异常的所述Slave主机配置的子Agent发送异常检测请求。

S202：子Agent在接收到所述异常检测请求时，检测存在异常的所述Slave主机中是否存在异常容器，并将检测结果上报至所述主Agent。

S203：主Agent根据所述检测结果确定存在异常的Slave主机中存在异常容器后，向该存在异常的Slave主机配置的子Agent发送指明异常容器的僵尸容器检测请求。

S204：子Agen基于所述异常容器与对应的容器组的运行状态比对结果，和\或，所述异常容器返回响应的情况，确定所述异常容器是否为僵尸容器。

上述S201-S204可参考上一实施例进行理解，在此不再赘述。

S301：如果所述子Agent确定该异常容器为僵尸容器，则将所述僵尸容器返回至所述主Agent。

S302：所述主Agent触发对所述僵尸容器的删除操作。

本申请实施例中，子Agent在确定该异常容器为僵尸容器后，将该僵尸容器上报至主Agent，由主Agent触发对该僵尸容器的删除操作。

一种可选的实施方式中，可以由主Agent删除该僵尸容器对应的pod。由于僵尸容器运行于pod中，因此，删除僵尸容器对应pod，即完成该僵尸容器的删除任务。

另一种可选的实施方式中，主Agent在接收到子Agent上报的僵尸容器后，可以向该子Agent发送指示其请求Docker删除该僵尸容器的容器删除命令，以使该子Agent请求Docker删除该僵尸容器。由于僵尸容器的运行依赖于Docker，因此，强制删除Docker即完成该僵尸容器的删除任务。

另一种可选的实施方式中，主Agent在接收到子Agent上报的僵尸容器后，可以向该子Agent发送指示其删除该僵尸容器对应的进程的容器删除命令，以使该子Agent删除该僵尸容器对应的进程。由于僵尸容器对应的进程一旦删除后，该僵尸容器也就不存在了，因此，强制删除该僵尸容器对应的进程，即完成该僵尸容器的删除任务。另外，通过删除进程的方式删除僵尸容器，与上述删除Docker的方式相比，能够防止删除操作对Docker环境的影响。

另一种可选的实施方式中，为了确保僵尸容器能够被成功删除，本申请实施例提供了一种僵尸容器的删除方法，参考图4，为本申请实施例提供的一种僵尸容器的删除方法的数据交互图。具体的，该方法包括：

S401：主Agent删除所述僵尸容器对应的pod。

S402：如果主Agent未成功删除所述pod，则主Agent向所述子Agent发送第一容器删除命令。

S403：所述子Agent请求Docker删除所述僵尸容器；

S404：如果子Agent未成功请求Docker删除所述僵尸容器，则主Agent向所述子Agent发送第二容器删除命令。

S405：子Agent删除所述僵尸容器对应的进程。

本申请实施例提供的僵尸容器的检测方法中，不仅能够实现对僵尸容器的检测，还能够完成对僵尸容器的及时删除，以降低僵尸容器的影响。

另外，本申请实施例能够确保对僵尸容器的成功删除，避免僵尸容器造成应用异常难以修复，严重时可能影响整个Docker环境的正常运行的情况发生。

与上述方法实施例相对应的，本申请还提供了一种僵尸容器的检测装置，参考图5，为本申请实施例提供的一种僵尸容器的检测装置的结构示意图。

其中，所述装置应用于容器集群管理***，所述容器集群管理***包括Master主机和Slave主机，所述Master主机配置有主Agent，所述Slave主机配置有子Agent，所述装置500包括主Agent510和子Agent520；所述主Agent510包括第一发送模块501和第二发送模块502；所述子Agent520包括第一检测模块503、上报模块504和第二检测模块505；

所述第一发送模块501，用于在确定任一Slave主机存在异常时，向存在异常的所述Slave主机配置的子Agent发送异常检测请求；

所述第一检测模块502，用于在接收到所述异常检测请求时，检测存在异常的所述从主机中是否存在异常容器；

所述上报模块503，用于将所述第一检测模块得检测结果上报至所述主代理；

所述第二发送模块504，用于根据所述检测结果确定存在异常的所述Slave主机中存在异常容器后，向存在异常所述Slave主机配置的子Agent发送指明所述异常容器的僵尸容器检测请求；

所述第二检测模块505，用于基于所述异常容器与对应的容器组的运行状态比对结果，和\或，所述异常容器返回响应的情况，确定所述异常容器是否为僵尸容器。

本申请提供的僵尸容器检测装置中，通过先确定存在异常的从主机，然后进一步确定该存在异常的从主机上的异常容器，最终确定该异常容器是否为僵尸容器的方式，逐层实现对僵尸容器的检测。另外，本申请基于异常容器与对应容器组的运行状态比对结果、异常容器返回响应的情况，能够准确确定出异常容器是否为僵尸容器。

另外，本申请实施例还提供了一种僵尸容器的检测设备，参见图6所示，可以包括：

处理器601、存储器602、输入装置603和输出装置604。僵尸容器的检测设备中的处理器601的数量可以一个或多个，图6中以一个处理器为例。在本发明的一些实施例中，处理器601、存储器602、输入装置603和输出装置604可通过总线或其它方式连接，其中，图6中以通过总线连接为例。

存储器602可用于存储软件程序以及模块，处理器601通过运行存储在存储器602的软件程序以及模块，从而执行僵尸容器的检测设备的各种功能应用以及数据处理。存储器602可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需的应用程序等。此外，存储器602可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。输入装置603可用于接收输入的数字或字符信息，以及产生与僵尸容器的检测设备的用户设置以及功能控制有关的信号输入。

具体在本实施例中，处理器601会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器602中，并由处理器601来运行存储在存储器602中的应用程序，从而实现上述僵尸容器的检测方法中的各种功能。

另外，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在终端设备上运行时，使得所述终端设备执行上述的僵尸容器的检测方法。

可以理解的是，对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本申请实施例所提供的一种僵尸容器的检测方法、装置及设备进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种僵尸容器的检测方法，其特征在于，所述方法应用于容器集群管理***，所述容器集群管理***包括雇主主机和从主机，所述雇主主机配置有主代理，所述从主机配置有子代理，所述方法包括：

所述主代理在确定任一从主机存在异常时，向存在异常的所述从主机配置的子代理发送异常检测请求；

所述子代理在接收到所述异常检测请求时，检测存在异常的所述从主机中是否存在异常容器，并将检测结果上报至所述主代理；

所述主代理根据所述检测结果确定存在异常的所述从主机中存在异常容器后，向存在异常的所述从主机配置的子代理发送指明所述异常容器的僵尸容器检测请求；

所述子代理基于所述异常容器与对应的容器组的运行状态比对结果，和\或，所述异常容器返回响应的情况，确定所述异常容器是否为僵尸容器；如果所述子代理确定所述异常容器为僵尸容器，则将所述僵尸容器返回至所述主代理。

2.根据权利要求1所述的方法，其特征在于，所述检测存在异常的从主机中是否存在异常容器，包括：

确定存在异常的从主机的应用容器引擎中运行的各个容器组分别对应的容器；将所述各个容器组分别对应的容器与预设容器列表中存储的各个容器组分别对应的容器进行比对，以确定所述存在异常的从主机中是否存在异常容器；其中，所述异常容器为所述应用容器引擎中与所述预设容器列表比对不一致的容器；

和\或，

获取预设进程资源占用列表中占用资源量大的前N项进程；确定所述前N项进程占用的***资源是否存在异常，以确定所述存在异常的从主机中是否存在异常容器；其中，所述异常容器为占用的***资源存在异常的进程对应的容器。

3.根据权利要求2所述的方法，其特征在于，所述获取预设进程资源占用列表中占用资源量大的前N项进程之前，还包括：

检测所述从主机的应用容器引擎是否存在运行异常；

如果确定所述从主机的应用容器引擎存在运行异常，则触发所述获取预设进程资源占用列表中占用资源量大的前N项进程步骤的执行。

4.根据权利要求3所述的方法，其特征在于，所述检测所述从主机的应用容器引擎是否存在运行异常，包括：

向所述从主机的应用容器引擎发送预设***命令，以获得所述应用容器引擎的响应时间；

通过确定所述响应时间是否异常，确定所述应用容器引擎是否存在运行异常。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述子代理基于所述异常容器与对应的容器组的运行状态比对结果，和\或，所述异常容器返回响应的情况，确定所述异常容器是否为僵尸容器，包括：

所述子代理检测所述异常容器对应的容器组的运行状态与所述异常容器的运行状态是否一致，以确定所述异常容器是否为僵尸容器；其中，所述僵尸容器为与对应的容器组的运行状态不一致的异常容器；

或者，

所述子代理向所述异常容器发送预设次数的请求，以确定所述异常容器是否为僵尸容器；其中，所述僵尸容器为未返回响应的异常容器；

或者，

所述子代理检测所述异常容器对应的容器组的运行状态与所述异常容器的运行状态是否一致；如果一致，则向所述异常容器发送预设次数的请求，以确定所述异常容器是否为僵尸容器；其中，所述僵尸容器为未返回响应的异常容器。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述主代理删除所述僵尸容器对应的容器组；或者，所述主代理向所述子代理发送容器删除命令；其中，所述容器删除命令用于指示所述子代理请求应用容器引擎删除所述僵尸容器，或者，用于指示所述子代理删除所述僵尸容器对应的进程。

7.根据权利要求6所述的方法，其特征在于，所述主代理删除所述僵尸容器对应的容器组之后，所述方法还包括：

如果所述主代理未成功删除所述容器组，则所述主代理向所述子代理发送第一容器删除命令，以使所述子代理请求应用容器引擎删除所述僵尸容器；

或者，所述主代理向所述子代理发送容器删除命令之后，还包括：

如果所述子代理未成功请求应用容器引擎删除所述僵尸容器，则所述主代理向所述子代理发送第二容器删除命令，以使所述子代理删除所述僵尸容器对应的进程。

8.一种僵尸容器的检测装置，其特征在于，所述装置应用于容器集群管理***，所述容器集群管理***包括雇主主机和从主机，所述雇主主机配置有主代理，所述从主机配置有子代理，所述装置包括主代理和子代理；所述主代理包括第一发送模块和第二发送模块；所述子代理包括第一检测模块、上报模块和第二检测模块；

所述第一发送模块，用于在确定任一从主机存在异常时，向存在异常的所述从主机配置的子代理发送异常检测请求；

所述第一检测模块，用于在接收到所述异常检测请求时，检测存在异常的所述从主机中是否存在异常容器；

所述上报模块，用于将所述第一检测模块得检测结果上报至所述主代理；

所述第二发送模块，用于根据所述检测结果确定存在异常的所述从主机中存在异常容器后，向存在异常所述从主机配置的子代理发送指明所述异常容器的僵尸容器检测请求；

所述第二检测模块，用于基于所述异常容器与对应的容器组的运行状态比对结果，和\或，所述异常容器返回响应的情况，确定所述异常容器是否为僵尸容器，如果确定所述异常容器为僵尸容器，则将所述僵尸容器返回至所述主代理。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当所述指令在终端设备上运行时，使得所述终端设备执行如权利要求1-7任一项所述的方法。

10.一种僵尸容器的检测设备，其特征在于，包括：存储器，处理器，及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时，实现如权利要求1-7任一项所述的方法。

Images