CN110535717B - 一种容器检测方法及装置 - Google Patents

Abstract

本发明提供一种容器检测方法及装置，容器编排引擎Kubernetes向容器发送检测请求，并记录请求次数，若超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，修改超时时间TimeoutSeconds，得到新的超时时间，返回执行向容器发送检测请求这一步骤，使容器在新的超时时间内进行检测，若超时时间内容器编排引擎Kubernetes接收到容器反馈的检测结果，则保持超时时间TimeoutSeconds不变，返回执行向容器发送检测请求这一步骤，使容器以超时时间内进行检测，若请求次数大于预设请求次数，且在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，则重启容器。解决容器编排引擎Kubernetes在检测性能较差的容器时，由于检测的时间超时而导致容器无限重启的问题。

Description

一种容器检测方法及装置

技术领域

本发明属于计算机技术领域，具体为涉及一种容器检测方法及装置。

背景技术

随着科学技术的进步，通过了解容器的存活状态的好坏，能够及时的对容器进行重启，及时恢复容器的工作状态。而对容器存活状态的检测可通过容器编排引擎Kubernetes检测容器的存活状态，通过容器编排引擎Kubernetes判断容器的检测时间是否大于超时时间TimeoutSeconds，若大于，重启容器。

但是，这种检测的方法灵活性较差，忽视了容器性能对检测结果返回速度的影响，进而影响检测时间。例如：在性能较好的容器上，返回时间为几毫秒，在性能较差的容器上，返回时间可能为几百毫秒甚至几秒，如果容器无法在指定的检测时间内返回检测结果，那么导致容器无限重启，从而使得容器无法提供正常的服务。

发明内容

有鉴于此，本发明的目的在于提供一种容器检测方法及装置，用于解决容器编排引擎Kubernetes在检测性能较差的容器时，由于检测的时间超时而导致容器无限重启的问题。技术方案如下：

本发明实施例提供一种容器检测方法，所述方法包括：

容器编排引擎Kubernetes向容器发送检测请求，并记录请求次数；

若超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，修改所述超时时间TimeoutSeconds，得到新的超时时间，返回执行向容器发送检测请求这一步骤，使所述容器在所述新的超时时间内进行检测；

若所述超时时间内所述容器编排引擎Kubernetes接收到所述容器反馈的检测结果，则保持所述超时时间TimeoutSeconds不变，返回执行向容器发送检测请求这一步骤，使所述容器以所述超时时间内进行检测；

若所述请求次数大于预设请求次数，且在所述超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，则重启所述容器。

优选的，若所述超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，修改所述超时时间TimeoutSeconds，得到新的超时时间，包括：

若在所述超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果；

在所述超时时间TimeoutSeconds上增加预设时间增幅参数，得到新的超时时间。

优选的，若所述预设时间增幅参数为1S，在所述超时时间TimeoutSeconds上增加预设时间增幅参数，得到新的超时时间，包括：

在所述超时时间TimeoutSeconds上增加1S，获得新的超时时间。

优选的，所述容器编排引擎Kubernetes向容器发送检测请求，包括：

若所述请求次数不大于所述预设请求次数，返回执行向容器发送检测请求这一步骤。

优选的，若所述预设请求次数为5次，所述请求次数大于预设请求次数，且在所述超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，则重启所述容器，包括：

若所述请求次数大于5次，且在所述超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，则重启所述容器。

本发明实施例还提供一种容器检测装置，所述装置包括：

发送模块，用于容器编排引擎Kubernetes向容器发送检测请求，并记录请求次数；

第一执行模块，用于若超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，修改所述超时时间TimeoutSeconds，得到新的超时时间，返回执行所述发送模块，使所述容器在所述新的超时时间内进行检测；

第二执行模块，用于若超时时间内所述容器编排引擎Kubernetes接收到所述容器反馈的检测结果，则保持所述超时时间TimeoutSeconds不变，返回执行所述发送模块，使所述容器以所述超时时间内进行检测；

重启模块，用于若所述请求次数大于预设请求次数，且在所述超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，则重启所述容器。

优选的，所述第一执行模块，包括：

反馈单元，用于若在所述超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果；

增加单元，用于在所述超时时间TimeoutSeconds上增加预设时间增幅参数，得到新的超时时间。

优选的，所述增加单元，包括：

增加子单元，用于在所述超时时间TimeoutSeconds上增加1S，获得新的超时时间。

优选的，所述发送模块，包括：

执行单元，用于若所述请求次数不大于所述预设请求次数，返回执行所述发送模块。

优选的，所述重启模块，包括：

重启单元，用于若所述请求次数大于5次，且在所述超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，则重启所述容器。

与现有技术相比，本发明提供的上述技术方案具有如下优点：

容器编排引擎Kubernetes向容器发送检测请求，并记录请求次数，若超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，修改超时时间TimeoutSeconds，得到新的超时时间，返回执行向容器发送检测请求这一步骤，使容器在新的超时时间内进行检测，若超时时间内容器编排引擎Kubernetes接收到容器反馈的检测结果，则保持超时时间TimeoutSeconds不变，返回执行向容器发送检测请求这一步骤，使容器以超时时间内进行检测，若请求次数大于预设请求次数，且在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，则重启容器。解决容器编排引擎Kubernetes在检测性能较差的容器时，由于检测的时间超时而导致容器无限重启的问题。

附图说明

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

图1是本发明实施例提供的一种容器检测方法的流程图；

图2是本发明实施例提供的一种修改超时时间TimeoutSeconds，得到新的超时时间的流程图；

图3是本发明实施例提供的一种若预设时间增幅参数为1S，在超时时间TimeoutSeconds上增加预设时间增幅参数，得到新的超时时间的流程图；

图4是本发明实施例提供的一种重启容器的流程图；

图5是本发明实施例提供的一种容器检测装置的结构示意图。

具体实施方式

本发明提供了一种容器检测方法及装置，用于解决容器编排引擎Kubernetes在检测性能较差的容器时，由于检测的时间超时而导致容器无限重启的问题。

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

如图1所示，示出了本发明实施例提供的一种容器检测方法，该方法包括以下步骤：

S101:容器编排引擎Kubernetes向容器发送检测请求，并记录请求次数。

在S101中，容器编排引擎kubernetes，简称K8s，是用数字8代替8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效(powerful)，Kubernetes提供了应用部署，规划，更新，维护的一种机制。

具体的，Kubernetes是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。

在Kubernetes中，可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。

在执行S101的过程中，容器编排引擎Kubernetes检测容器的存活状态，即检测该容器的服务性能是否良好，每一次容器编排引擎Kubernetes向相应的容器发送检测请求时，都会记录对该容器检测的请求次数。

例如：容器编排引擎Kubernetes向容器发送第一次检测请求，那么该容器编排引擎Kubernetes记录对容器发送检测请求的次数为1次，当容器编排引擎Kubernetes对容器第二次进行检测时，则发送第二次检测请求，并记录请求次数为2次。

需要说明的是，容器编排引擎Kubernetes向容器发送检测请求，并记录请求次数，能有效的检测到如果容器的存活状态有问题，就能知道哪一次检测有问题。

S102:判断在超时时间内容器编排引擎Kubernetes是否接收到容器反馈的检测结果，若否，则执行S103，若是，执行S104。

在执行S102的过程中，容器编排引擎Kubernetes向容器发送检测请求后，需要等待并获得容器反馈的检测结果，而等待的时间是预先设置好的，在该预设的时间内，即超时时间内，判断容器编排引擎Kubernetes是否接收到反馈的检测结果。

需要说明的是，超时时间根据实际情况进行设置，这里不再进行赘述。

S103:修改超时时间TimeoutSeconds，得到新的超时时间，返回执行S101这一步骤，使容器在新的超时时间内进行检测。

在S103中，超时时间TimeoutSeconds为一个参数，该参数的功能为用于存储超时时间的数值，且该超时时间TimeoutSeconds能被修改，即存储在超时时间TimeoutSeconds中的超时时间的数值能被修改。

例如：假设该超时时间TimeoutSeconds存储的预设时间的数值为1秒，若被修改后，用于存储超时时间数值的超时时间TimeoutSeconds为2秒。即原来的预设时间的数值从1修改为了2。

在执行S103的过程中，在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，则对超时时间TimeoutSeconds进行修改之后，返回执行S101这一步骤，使得容器在新的超时时间内进行检测。

需要说明的是，在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，容器也不会重启，而是修改超时时间TimeoutSeconds，等待下一次的检测，解决了虽然容器的存活状态良好，但是由于响应检测结果的时间较慢会导致容器编排引擎Kubernetes认为该容器异常，从而不断重启该容器的问题。

S104:保持超时时间TimeoutSeconds不变，返回执行S101这一步骤，使容器以超时时间内进行检测。

在执行S104的过程中，在超时时间内容器编排引擎Kubernetes接收到容器反馈的检测结果，则不对超时时间TimeoutSeconds进行修改，然后返回执行S101这一步骤，使得容器同样以该超时时间内进行检测。

需要说明的是，在超时时间内容器编排引擎Kubernetes接收到容器反馈的检测结果，不对超时时间TimeoutSeconds进行修改，说明该容器的存活状态良好，没有异常。继续进行下一次的检测。

S105:判断请求次数是否大于预设请求次数，且在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，若是，执行S106，若否，执行S101。

在执行S105的过程中，每记录一次请求次数，需要判断请求次数是否大于预设请求次数，根据请求次数大于或小于预设请求次数，执行相应的操作。

S106:重启容器。

在执行S106的过程中，如果容器编排引擎Kubernetes对容器发送检测请求的次数大于预设请求次数时，而且在预设时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，说明容器的存活状态异常。则需要重启该容器。

需要说明的是，预设请求次数的数值，在对应的参数中进行存储。

基于上述本发明实施例公开的容器检测方法，容器编排引擎Kubernetes向容器发送检测请求，并记录请求次数，若超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，修改超时时间TimeoutSeconds，得到新的超时时间，返回执行向容器发送检测请求这一步骤，使容器在新的超时时间内进行检测，若超时时间内容器编排引擎Kubernetes接收到容器反馈的检测结果，则保持超时时间TimeoutSeconds不变，返回执行向容器发送检测请求这一步骤，使容器以超时时间内进行检测，若请求次数大于预设请求次数，且在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，则重启容器。解决容器编排引擎Kubernetes在检测性能较差的容器时，由于检测的时间超时而导致容器无限重启的问题。

根据上述本发明实施例公开的容器检测方法涉及到的，若超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，修改所述超时时间TimeoutSeconds，得到新的超时时间的具体实现过程，如图2所示，主要包括：

S201:判断在超时时间内容器编排引擎Kubernetes是否接收到容器反馈的检测结果，若否，执行S202，若是，执行S104。

上述S201的执行原理和上述S102的一致，这里不再进行赘述。

S202:在超时时间TimeoutSeconds上增加预设时间增幅参数，得到新的超时时间。

在S202中，预设时间增幅参数为固定的数值。在执行S202的过程中，如果在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，则使得超时时间TimeoutSeconds在原来数值的基础上加上一个预设时间增幅参数，作为下一次容器编排引擎Kubernetes检测容器时，判断容器反馈结果的超时时间。

需要说明的是，预设时间增幅参数可根据实际情况进行设定，这里不再进行赘述。

根据上述本发明实施例公开的容器检测方法可知，给定一个预设时间增幅参数，若在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，则超时时间TimeoutSeconds加上预设时间增幅参数，这样使得超时时间TimeoutSeconds变大，即反馈检测结果的时间延长。这样就能够解决在容器的存活状态良好情况下，但是由于响应检测结果的时间较慢会导致容器编排引擎Kubernetes认为该容器异常，从而不断重启该容器的问题。

基于上述本发明实施例公开的容器检测方法涉及到的，若预设时间增幅参数为1S，在超时时间TimeoutSeconds上增加预设时间增幅参数，得到新的超时时间的具体实现过程，如图3所示，主要包括：

S301:判断在超时时间内容器编排引擎Kubernetes是否接收到容器反馈的检测结果，若否，执行S302，若是，执行S104。

上述S301的执行原理和上述S102的一致，这里不再进行赘述。

S302:在超时时间TimeoutSeconds上增加1S，获得新的超时时间。

在执行S302的过程中，如果在超时时间内，容器编排引擎Kubernetes未接收到容器反馈的检测结果，则使得超时时间TimeoutSeconds在原来数值的基础上加上一个1S的数值作为新的超时时间，用于判断下一次容器编排引擎Kubernetes检测容器时容器反馈结果的超时时间。

需要说明的是，超时时间TimeoutSeconds包括增加1S但不限于1S，具体的根据实际情况进行设定，这里不在进行赘述。

根据上述本发明实施例公开的容器检测方法可知，给定一个预设时间增幅参数，若在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，则超时时间TimeoutSeconds加上预设时间增幅参数，这样使得超时时间TimeoutSeconds变大，即反馈检测结果的时间延长。这样就能够解决在容器的存活状态良好情况下，但是由于响应检测结果的时间较慢会导致容器编排引擎Kubernetes认为该容器异常，从而不断重启该容器的问题。

基于上述本发明实施例公开的容器检测方法涉及到的，若预设请求次数为5次，请求次数大于预设请求次数，且在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，则重启容器的具体实现过程，如图4所示，主要包括：

S401:判断请求次数是否大于5次，且在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，若是，执行S402，若否，执行S101。

在执行S401的过程中，每记录一次请求次数，需要判断请求次数是否大于5次，如果大于5次，说明用于检测容器的次数已经用完。当下次检测时即第6次检测容器时，在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，执行S402。

S402:重启容器。

S402的执行原理和上述S106的一致，这里不再进行赘述。

根据上述本发明实施例公开的容器检测方法可知，容器编排引擎Kubernetes向容器发送检测请求，并记录请求次数，若超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，修改超时时间TimeoutSeconds，得到新的超时时间，返回执行向容器发送检测请求这一步骤，使容器在新的超时时间内进行检测，若超时时间内容器编排引擎Kubernetes接收到容器反馈的检测结果，则保持超时时间TimeoutSeconds不变，返回执行向容器发送检测请求这一步骤，使容器以超时时间内进行检测，若请求次数大于预设请求次数，且在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，则重启容器。解决容器编排引擎Kubernetes在检测性能较差的容器时，由于检测的时间超时而导致容器无限重启的问题。

基于上述本发明实施例公开的一种容器检测方法，本发明实施例还对应公开一种容器检测装置，如图5所示，为本发明实施例提供的一种容器检测装置的结构示意图，主要包括：发送模块50、第一执行模块51、第二执行模块52和重启模块53。

发送模块50，用于容器编排引擎Kubernetes向容器发送检测请求，并记录请求次数。

第一执行模块51，用于若超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，修改超时时间TimeoutSeconds，得到新的超时时间，返回执行发送模块，使容器在新的超时时间内进行检测。

第二执行模块52，用于若超时时间内容器编排引擎Kubernetes接收到服务器反馈的检测结果，则保持超时时间TimeoutSeconds不变，返回执行发送模块，使容器以超时时间内进行检测。

重启模块53，用于若请求次数大于预设请求次数，且在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，则重启容器。

基于上述本发明实施例公开的容器检测装置，容器编排引擎Kubernetes向容器发送检测请求，并记录请求次数，若超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，修改超时时间TimeoutSeconds，得到新的超时时间，返回执行发送模块这一步骤，使容器在新的超时时间内进行检测，若超时时间内容器编排引擎Kubernetes接收到容器反馈的检测结果，则保持超时时间TimeoutSeconds不变，返回执行发送模块这一步骤，使容器以超时时间内进行检测，若请求次数大于预设请求次数，且在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，则重启容器。解决容器编排引擎Kubernetes在检测性能较差的容器时，由于检测的时间超时而导致容器无限重启的问题。

在本发明装置实施例中第一执行模块51的一种可选结构为：第一执行模块51包括反馈单元和增加单元。

反馈单元，用于若在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果。

增加单元，用于在超时时间TimeoutSeconds上增加预设时间增幅参数，得到新的超时时间。

具体的增加单元包括：增加子单元。

增加子单元，用于在超时时间TimeoutSeconds上增加1S，获得新的超时时间。

根据上述本发明实施例公开的容器检测方法装置，给定一个预设时间增幅参数，若在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，则超时时间TimeoutSeconds加上预设时间增幅参数，这样使得超时时间TimeoutSeconds变大，即反馈检测结果的时间延长。这样就能够解决在容器的存活状态良好情况下，但是由于响应检测结果的时间较慢会导致容器编排引擎Kubernetes认为该容器异常，从而不断重启该容器的问题。

在本发明装置实施例中发送模块50的另一种可选结构为：发送模块50包括执行单元。

执行单元，用于若请求次数不大于预设请求次数，返回执行发送模块。

在本发明装置实施例中重启模块53的一种可选结构为：重启模块53包括重启单元，用于若请求次数大于5次，且在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，则重启容器。

基于上述本发明实施例公开的容器检测装置，容器编排引擎Kubernetes向容器发送检测请求，并记录请求次数，若超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，修改超时时间TimeoutSeconds，得到新的超时时间，返回执行发送模块这一步骤，使容器在新的超时时间内进行检测，若超时时间内容器编排引擎Kubernetes接收到容器反馈的检测结果，则保持超时时间TimeoutSeconds不变，返回执行发送模块这一步骤，使容器以超时时间内进行检测，若请求次数大于预设请求次数，且在超时时间内容器编排引擎Kubernetes未接收到容器反馈的检测结果，则重启容器。解决容器编排引擎Kubernetes在检测性能较差的容器时，由于检测的时间超时而导致容器无限重启的问题。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (8)

1.一种容器检测方法，其特征在于，所述方法包括：

容器编排引擎Kubernetes向容器发送检测请求，并记录请求次数；

若超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，在所述超时时间TimeoutSeconds上增加预设时间增幅参数，得到新的超时时间，返回执行向容器发送检测请求这一步骤，使所述容器在所述新的超时时间内进行检测；

若所述超时时间内所述容器编排引擎Kubernetes接收到所述容器反馈的检测结果，则保持所述超时时间TimeoutSeconds不变，返回执行向容器发送检测请求这一步骤，使所述容器以所述超时时间内进行检测；

若所述请求次数大于预设请求次数，且在所述超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，则重启所述容器。

2.根据权利要求1所述的方法，其特征在于，若所述预设时间增幅参数为1S，在所述超时时间TimeoutSeconds上增加预设时间增幅参数，得到新的超时时间，包括：

在所述超时时间TimeoutSeconds上增加1S，获得新的超时时间。

3.根据权利要求1所述的方法，其特征在于，所述容器编排引擎Kubernetes向容器发送检测请求，包括：

若所述请求次数不大于所述预设请求次数，返回执行向容器发送检测请求这一步骤。

4.根据权利要求1所述的方法，其特征在于，若所述预设请求次数为5次，所述请求次数大于预设请求次数，且在所述超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，则重启所述容器，包括：

若所述请求次数大于5次，且在所述超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，则重启所述容器。

5.一种容器检测装置，其特征在于，所述装置包括：

发送模块，用于容器编排引擎Kubernetes向容器发送检测请求，并记录请求次数；

第一执行模块，用于若超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，在所述超时时间TimeoutSeconds上增加预设时间增幅参数，得到新的超时时间，返回执行所述发送模块，使所述容器在所述新的超时时间内进行检测；

第二执行模块，用于若所述超时时间内所述容器编排引擎Kubernetes接收到所述容器反馈的检测结果，则保持所述超时时间TimeoutSeconds不变，返回执行所述发送模块，使所述容器以所述超时时间内进行检测；

重启模块，用于若所述请求次数大于预设请求次数，且在所述超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，则重启所述容器。

6.根据权利要求5所述的装置，其特征在于，所述第一执行模块，包括：

增加子单元，用于在所述超时时间TimeoutSeconds上增加1S，获得新的超时时间。

7.根据权利要求5所述的装置，其特征在于，所述发送模块，包括：

执行单元，用于若所述请求次数不大于所述预设请求次数，返回执行所述发送模块。

8.根据权利要求5所述的装置，其特征在于，所述重启模块，包括：

重启单元，用于若所述请求次数大于5次，且在所述超时时间内所述容器编排引擎Kubernetes未接收到所述容器反馈的检测结果，则重启所述容器。

Images