CN114546586A - 一种容器资源限制、故障监视及恢复方法 - Google Patents

Abstract

本发明公开了云计算大数据领域的一种容器资源限制、故障监视及恢复方法，其包括：获取容器的启动进程PID并将其设置到容器所属cgroup资源限制组中，设置cgroup资源限制值；指定容器cgroup的systemd资源限制组为非系统资源限制组；执行容器command命令启动容器的首进程；若容器首进程启动成功，则更新容器状态为运行中并记录容器首进程PID；销毁容器启动进程，宿主机1号进程接管容器首进程,以实现容器资源分离式限制。本发明能够使容器管理系统组件间耦合性更低、更加简单可靠，容器的稳定性和可维护性更强，并具有自我恢复功能，当本地容器故障时，支持快速跨主机同步镜像文件和恢复容器。

Description

一种容器资源限制、故障监视及恢复方法

技术领域

本发明涉及一种容器资源限制、故障监视及恢复方法，属于云计算大数据技术领域。

背景技术

以docker为代表的容器引擎技术是一种轻量级虚拟化技术。在Linux操作系统中，容器主要通过Control Group（控制组）实现资源配额限制，资源包括CPU资源、内存资源、IO资源等。docker中使用containerd-shim容器垫片作为每个真实容器的常驻父进程，容器垫片的主要作用是监控容器的进程状态并为容器的cgroup资源限制提供一个常驻父进程。但容器垫片一旦出现异常掉线，对应的用户容器所有进程也将同时消失，且容器垫片需要升级时，也必须停掉所有的用户容器，这对于容器的稳定性和可维护性提出了较大的挑战。

Kubernetes是一个基于容器技术的分布式架构领先方案，提供了容器化的应用部署运行、资源调度、服务发现和动态伸缩等一系列功能，提高了大规模容器集群管理的便捷性和高可用性。但是，Kubernetes本身更倾向于容器中运行单个或少量业务进程，然后通过对每个容器本身的健康状态进行监控实现分布式管理和监视，对于存在大量进程的大型工程化软件来说并不完全适用，因为为每一个进程分配一个容器进行管理并不现实，而当大量业务进程集中在一个容器中时，现有技术中只关注了每个容器本身的运行状态，并不能细粒度的监视每个容器中的每个业务进程的健康状态。并且当大量业务进程集中在同一个容器中时，对容器本身的稳定性和可维护性也提出了更高的要求，容器中进程多的同时也导致容器和所对应的镜像文件占用的磁盘空间更大，同时也涉及到当容器镜像文件很大时如何快速跨主机恢复容器的问题。

发明内容

本发明的目的在于克服现有技术中的不足，提供一种容器资源限制、故障监视及恢复方法，解决现有技术中容器管理系统的稳定性和可维护性差，不能细粒度的监视每个容器中的每个业务进程的健康状态、不能快速跨主机恢复容器等技术问题。

为解决上述技术问题，本发明是采用下述技术方案实现的：

第一方面，本发明提供了一种容器资源限制方法，所述方法包括如下步骤：

获取容器的启动进程PID并将其设置到容器所属cgroup资源限制组中，设置cgroup资源限制值；

指定容器cgroup的systemd资源限制组为非系统资源限制组；

执行容器command命令启动容器的首进程；

若容器首进程启动成功，则更新容器状态为运行中并记录容器首进程PID；

销毁容器启动进程，宿主机1号进程接管容器首进程,以实现容器资源分离式限制。

进一步的，所述cgroup资源限制组包括CPU的资源限制组和内存的资源限制组。

进一步的，所述指定容器cgroup的systemd资源限制组为非系统资源限制组之后，还包括：通过镜像目录联合挂载生成容器目录、创建容器命名空间。

进一步的，若容器首进程启动不成功，则释放容器mount挂载点和cgroup资源并更新容器运行状态为退出。

进一步的，容器首进程启动成功后还包括：将容器首进程作为容器启动进程的子进程、容器的业务进程作为容器首进程的子进程添加到cgroup资源限制列表中。

第二方面，本发明提供了一种容器故障监视方法，由宿主机执行，所述方法包括如下步骤：

将启动成功的容器加入周期性监视容器列表中；

当容器业务进程掉线时，进入对应容器命名空间中尝试拉起掉线的容器业务进程：若容器业务进程拉起失败，且拉起失败的容器业务进程为关键进程，则将相应容器配置为故障状态。

进一步的，所述方法包括：监视容器首进程运行状态：当容器首进程的运行状态为非正常时，进一步判断容器状态是否为退出状态，若不为退出状态，则释放容器mount挂载点和cgroup资源并更新容器运行状态为退出，同时从周期性监视列表移除对应容器。

进一步的，进入对应容器命名空间中尝试拉起掉线的容器业务进程的步骤包括：

获取容器业务进程启动命令和参数；

根据容器业务进程启动命令和参数找到宿主机上符合条件的一组容器业务进程PID，并根据之前启动容器时记录的每个容器首进程PID获取其命名空间；

根据容器业务进程的标识定位到业务进程所在的容器并重新进入容器命名空间中主动尝试拉起对应进程，同时将当前执行命令的进程PID加入cgroup容器资源限制组中；

其中，所述标识根据容器业务进程的特征值进行分类获取；所述特征值包括容器业务进程启动命令和参数、容器业务进程PID和所属命名空间描述符。

进一步的，尝试拉起掉线的容器业务进程的次数设置为三次，若三次拉起容器业务进程都失败，则将该容器业务进程状态设置为失败状态。

第三方面，本发明还提供一种容器恢复方法，所述容器运行在集群的其中一个宿主机上，所述集群中其余宿主机存放有所述容器的初始镜像；所述方法包括以下步骤：

响应于容器被配置为故障状态获取每个容器所使用的宿主机磁盘目录，并且针对每个容器在相应宿主机磁盘目录上的所有文件进行增加、删除和修改情况做增量标记；

配置时间间隔，定期将每个容器在相应宿主机磁盘目录上所有文件的增量标记进行更新，并将最新版本的文件同步到其余宿主机磁盘的文件中，同时删除同步标记；

检查还未同步完成的标记，执行同步后再使用最新的容器镜像启动容器，实现容器快速跨主机恢复。

与现有技术相比，本发明所达到的有益效果：

1. 本发明将容器资源采用分离式的限制方式，容器的资源限制组不依赖于任何外部进程，且不会因为任意一个外部进程的退出而消失，所有容器的管理程序包括容器命令行工具都可以在不影响用户容器进程运行状态的情况下升级更新，使容器管理系统组件间耦合性更低、更加简单可靠，容器的稳定性和可维护性更强；

2. 本发明对容器故障的监视管理中采用分离式的监视方法，对于多业务进程集中在一个容器中时，能细粒度的监视每个容器中的每个业务进程的健康状态，当容器内的业务进程掉线时，能够自动识别出此进程属于哪个容器，并主动尝试进入对应容器命名空间中拉起掉线的业务进程；

3.本发明针对本地容器发生故障时，支持快速跨主机同步镜像文件和恢复容器，从而使容器管理系统更适合工程化使用。

附图说明

图1是本发明实施例提供的一种容器资源限制的方法流程图；

图2是本发明实施例提供的一种容器故障监视方法的流程图；

图3是本发明实施例提供的监视容器内业务进程的运行状态说明示意图；

图4是本发明实施例提供的容器恢复时进行容器文件跨主机同步的示意图。

具体实施方式

下面通过附图以及具体实施例对本发明技术方案做详细的说明，应当理解本申请实施例以及实施例中的具体特征是对本申请技术方案的详细的说明，而不是对本申请技术方案的限定，在不冲突的情况下，本申请实施例以及实施例中的技术特征可以相互组合。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符"/"，一般表示前后关联对象是一种“或”的关系。

实施例一：

如图1所示，本发明实施例提供了一种容器资源限制方法，所述方法包括如下步骤：

启动指定容器，将容器启动进程自身PID设置到CPU、内存等cgroup资源限制组中，并设置CPU、内存等cgroup资源限制值；

指定容器进程的systemd资源限制组为非系统资源限制组，以摆脱系统服务对容器资源限制组的控制；

通过镜像目录联合挂载生成容器目录，随后创建容器命名空间；

执行容器的command命令启动容器的首进程；

若容器首进程启动不成功，则释放容器mount挂载点和cgroup资源并更新容器运行状态为退出；

容器首进程启动成功后，容器进程作为启动进程的子进程自动加入cgroup的进程限制列表；需要进一步说明的是：当容器首进程启动时，由于子进程在被fork出时会自动继承父进程所在cgroup资源限制组，因此，容器的首进程作为容器启动进程的子进程被自动添加到cgroup资源限制列表中，容器的其它由首进程拉起的业务进程作为容器首进程的子进程也自动被添加到cgroup资源限制列表中；

更新容器状态为运行中并记录容器首进程PID；

容器的启动进程结束后，容器启动进程销毁，容器的资源限制组不受任何外部进程的控制，容器首进程由宿主机1号进程接管,以实现容器资源分离式限制。

本发明实施例中由于宿主机的1号进程直接接管容器的首进程，资源限制模式也从cgroupfs自动切换为systemd方式，systemd资源限制方式默认要求资源限制组归属某个具体服务，如果不显式指定systemd资源限制组，当前容器资源限制组将会挂靠于最接近当前容器首进程环境上下文的某个系统服务单元上，该系统服务重启也会影响当前的容器cgroup资源限制组；因此需要显式指定容器cgroup的systemd资源限制组为非系统资源限制组；由于之前已经设置过systemd资源限制组为非系统资源限制组，因此，此时容器的cgroup资源限制组不受任何外部进程的控制从而实现分离式资源限制；所有容器的管理程序包括容器命令行工具都可以在不影响用户容器进程运行状态的情况下升级更新，使容器管理系统组件间耦合性更低、更加简单可靠，提高容器的稳定性。

实施例二：

本发明实施例提供了一种容器故障监视方法，该方法的实施环境是：基于实施例一所述的方法在容器启动成功后，容器首进程由宿主机1号进程接管。将容器进程分为首进程、持久化进程和业务进程，配置由容器首进程批量拉起多个业务进程并执行持久化进程以保持容器一直处于运行中。需要说明的是：所谓宿主机1号进程即为操作系统中的init进程。

如图2所示，本发明实施例提供的容器故障监视方法,可以由宿主机执行,具体的可以由宿主机中的分离监视程序实现,所述方法包括如下步骤：

获取容器进程运行状态，周期性监视文件中的容器状态；

判断容器是否启动成功；

若容器启动不成功，则该容器留在监视文件中继续监视；

若容器启动成功，则将启动成功的容器加入周期性监视容器列表中；

对于加入周期性监视容器列表中的容器,宿主机持续监视容器首进程运行状态、容器业务进程运行状态和/或容器业务状态。

参见图2，其中，持续监视容器首进程运行状态的方法包括：

判断容器首进程运行状态是否正常；

若容器首进程运行状态正常，则对该容器继续执行周期性监视；

若容器首进程的运行状态为非正常时，进一步判断容器状态是否为退出状态；

若该容器状态为退出状态，则从周期性监视列表移除对应容器；

若该容器状态不是退出状态，则释放容器mount挂载点和cgroup资源并更新容器运行状态为退出，同时从周期性监视列表移除对应容器。

持续监视容器业务进程运行状态的方法包括：

判断容器业务进程是否正常运行；

若容器业务进程运行状态正常，则对该容器继续执行周期性监视；

当容器业务进程掉线时，则根据记录的进程启动命令、参数和命名空间文件描述符进入容器命名空间主动尝试三次拉起容器业务进程；

若容器业务进程重新启动成功，则对该容器继续执行周期性监视；

若三次拉起容器业务进程都失败，则将该容器业务进程状态设置为失败状态；其中，本实施例中主动尝试拉起掉线容器业务进程的次数设置为3次，也可以根据需要设置为其它次数。

作为本发明的一种实施例，进入对应容器命名空间中尝试拉起掉线的容器业务进程流程具体为：

用户可以自由选择是在容器的command启动命令中配置自动批量拉起业务进程或是在容器的command仅仅执行容器持久化命令/bin/bash,并在容器启动成功后进入容器手工执行批量拉起业务进程；

获取容器业务进程启动命令和参数；

根据容器业务进程启动命令和参数找到宿主机上符合条件的一组容器业务进程PID，并根据之前启动容器时记录的每个容器首进程PID获取其命名空间，由于同一个容器中的所有进程的命名空间相同，因此根据之前启动容器时记录的容器首进程PID获取其命名空间；

将上报的业务进程启动命令和参数、业务进程PID和所属命名空间描述符等特征值分类，并作为一个容器业务进程的标识更新到内存并持久化到文件中；

根据容器业务进程的标识定位到业务进程所在的容器并重新进入容器命名空间中主动尝试拉起对应进程，同时将当前执行命令的进程PID加入cgroup容器资源限制组中。

持续监视容器业务状态的方法包括：

当监视到容器业务进程状态为失败状态时，判断该容器业务进程是否为关键进程；

若不是关键进程，则对该容器继续执行周期性监视；

若为关键进程，则将其相应容器配置为故障状态；实现容器故障分离式监视。

本发明实施例提供的容器故障监视方法，对于多业务进程集中在一个容器中时，能细粒度的监视每个容器中的每个业务进程的健康状态，当容器内的业务进程掉线时，能够自动识别出此进程属于哪个容器，并主动尝试进入对应容器命名空间中拉起掉线的业务进程；进一步提高了容器的稳定性和可维护性。

实施例三：

本实施例提供一种容器故障监视方法，该方法与实施例二基于相同的技术构思，均可在宿主机上启动分离式监视程序执行所述容器故障监视方法，以监视容器内业务进程的运行状态，其与实施例二的不同之处在于，本实施例结合实例对容器故障监视方法做出了进一步说明，具体如下：

如图3所示,宿主机上启动了两个容器，分别为容器a和容器b；其中，容器a中：/bin/bash /usr/sys103_start.sh为容器首进程，/bin/bash为持久化进程，app_warn、app_monitor、app_server均为业务进程；容器b中也启动了同样的业务进程。容器a中业务进程在进程启动注册时将进程启动命令和参数app_warn -service sys -inst 1，app_monitor-service sys -inst 1，app_server -service sys -inst 1上报给分离式监视程序。

分离式监视程序根据上报的业务进程启动命令和参数找到宿主机上符合条件的一组业务进程PID，根据这些PID到/proc/{pid}/ns目录下找到进程对应的命名空间文件描述符如app_server进程的ipc、mnt、net、pid、user、uts命名空间描述符分别为4026532625，4026532623，4026532628, 4026532626，4026531837，4026532624，这里同一个宿主机上ps-ef看可能存在多个启动命令和参数为app_server -service sys -inst 1的进程，且可能存在同名进程直接运行在宿主机上。由于同一个容器中的所有进程的命名空间相同，因此根据之前启动容器时记录的每个容器首进程PID获取其命名空间描述符，此处容器a和容器b的首进程PID分别为3670和3682，分别到/proc/3670/ns和/proc/3682/ns目录下找对容器的命名空间，以此作为筛选条件将上报的业务进程启动命令和参数、业务进程PID和所属命名空间描述符等特征值分类，这里因为在宿主机上查看到的app_server的PID有三个，分别是62369、65812、24562，识别到/proc/62369/ns目录下的命名空间文件描述符和容器a的首进程命名空间描述符一致，因此将宿主机上PID为62369、启动命令和参数为app_server -service sys -inst 1的业务进程分类归属到容器a下并更新到内存且持久化到文件中；识别到/proc/65812/ns目录下的命名空间文件描述符和容器b的首进程命名空间描述符一致，因此将宿主机上PID为65812、启动命令和参数为app_server -service sys -inst 1的业务进程分类归属到容器b下并更新到内存且持久化到文件中。PID为24562进程对应的/proc/24562/ns目录下的命名空间和容器a、容器b的首进程命名空间都不匹配，该进程为直接在宿主机上启动的业务进程，忽略对该进程的监视。

当分离式监视程序发现PID为62369的进程掉线，即对应容器a中PID为37的业务进程app_server掉线时，由分离式监视程序定位到业务进程所在的容器并根据之前记录的容器a的命名空间描述符重新进入容器命名空间中主动尝试三次拉起对应进程，同时将当前执行命令的进程PID加入到当前容器资源限制组中，以保证新拉起的业务进程维持原有资源限制和命名空间。当三次拉起业务进程都失败后，将该业务进程状态设置为失败。

本发明实施例中的容器故障监视方法，有别于常用的容器垫片作为每个真实容器的常驻父进程，容器垫片一旦出现异常掉线或升级，用户容器也将同时消失，本发明实施例使用分离式监视程序替代容器垫片实现容器的分离式监视，分离式监视程序为独立进程，与容器内进程不存在父子进程关系，分离式监视程序的创建和销毁不影响容器首进程的状态，即不影响容器的整体运行状态；分离式监视程序手工退出后具备重新拉起并恢复监视所有用户容器健康状态的能力。

此外，分离式监视程序退出不影响用户容器的正常运行，可以在不停止用户容器进程的情况下，临时停止分离式监视程序进行独立升级，即所有容器的管理程序都可以在不影响用户容器进程运行状态的情况下升级；并且当分离式监视程序出现异常挂掉，不影响用户容器的正常运行。

实施例四：

本发明实施例提供一种容器恢复方法，所述方法响应于实施例二或实施例三的监视结果，当容器被配置为故障状态时执行。其中，所述容器运行在集群的其中一个宿主机上，所述集群中其余宿主机存放有所述容器的初始镜像；所述方法包括以下步骤：

响应于容器被配置为故障状态，获取每个容器所使用的宿主机磁盘目录，并且针对每个容器在相应宿主机磁盘目录上的所有文件进行增加、删除和修改情况做增量标记；

配置时间间隔，定期将每个容器在相应宿主机磁盘目录上所有文件的增量标记进行更新，并将最新版本的文件同步到其余宿主机磁盘的文件中，同时删除同步标记；

检查还未同步完成的标记，执行同步后再使用最新的容器镜像启动容器，实现容器快速跨主机恢复。

如图4所示，给出了本发明实施例中分离式监视程序进行容器文件跨主机同步的解释说明：

当宿主机1上的容器1向容器内新增了一个文件c时，宿主机的挂载给容器1使用的目录中会增加一个文件c，分离式容器监视程序会标记容器1在某个路径增加了一个文件c；

当文件a和b是容器1内已有的文件，假设某个时刻容器1修改了文件a，则分离式容器监视程序会通过对特定目录订阅的操作系统监控消息发现容器1在其目录中修改了文件a，并在管理信息中标记修改了文件a，并记录修改时间；如果后面某个时刻容器1再次修改了文件a，则更新文件修改时间，文件名不变；如果容器1修改了增加的文件c，则分离式容器监视程序会在修改信息中标记文件c，在增加信息中删除文件c；

当某个时刻容器1删除了文件b，则分离式容器监视程序会通过对特定目录订阅的操作系统监控消息发现容器1在其目录中删除了文件b，并在管理信息中标记删除了文件b，并记录删除时间。

其中，一个宿主机上的所有容器统一被一个分离式容器监视程序管理，容器监视程序可通过配置时间间隔，定期的将宿主机1上的容器1和容器2相应文件的增加、删除及修改信息同步到集群的宿主机2，然后在宿主机2上进行合并，用以更新宿主机2的容器镜像；没有配置定期同步的容器则在进行容器迁移之前进行一次合并。在同步到宿主机2合并时，增加的文件直接放入原容器镜像所在目录，修改的文件进行替换，删除的文件通过标记的路径和文件名在原容器镜像中删除，所有容器的标记处理完毕后，合并生成新的容器镜像，可直接用于启动容器，实现容器快速跨主机恢复。

综上，本发明实施例提供的容器恢复方法，使容器管理系统组件间耦合性更低、更加简单可靠，容器的稳定性和可维护性更强，并具有自我恢复功能，对于多业务进程集中在一个容器中时，细粒度的监视每个容器中的每个业务进程的健康状态，当本地容器故障时，支持快速跨主机同步镜像文件和恢复容器；从而使容器管理系统更适合工程化使用。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

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

Claims (10)

1.一种容器资源限制方法，其特征在于，所述方法包括如下步骤：

获取容器的启动进程PID并将其设置到容器所属cgroup资源限制组中，设置cgroup资源限制值；

指定容器cgroup的systemd资源限制组为非系统资源限制组；

执行容器command命令启动容器的首进程；

若容器首进程启动成功，则更新容器状态为运行中并记录容器首进程PID；

销毁容器启动进程，宿主机1号进程接管容器首进程,以实现容器资源分离式限制。

2.根据权利要求1所述的容器资源限制方法，其特征在于，所述cgroup资源限制组包括CPU的资源限制组和内存的资源限制组。

3.根据权利要求2所述的容器资源限制方法，其特征在于，所述指定容器cgroup的systemd资源限制组为非系统资源限制组之后，还包括：

通过镜像目录联合挂载生成容器目录、创建容器命名空间。

4.根据权利要求3所述的容器资源限制方法，其特征在于，

若容器首进程启动不成功，则释放容器mount挂载点和cgroup资源并更新容器运行状态为退出。

5.根据权利要求4所述的容器资源限制方法，其特征在于，容器首进程启动成功后还包括：

将容器首进程作为容器启动进程的子进程、容器的业务进程作为容器首进程的子进程添加到cgroup资源限制列表中。

6.一种容器故障监视方法，其特征在于，由宿主机执行，所述方法包括如下步骤：

将启动成功的容器加入周期性监视容器列表中；

当容器业务进程掉线时，进入对应容器命名空间中尝试拉起掉线的容器业务进程：若容器业务进程拉起失败，且拉起失败的容器业务进程为关键进程，则将相应容器配置为故障状态。

7.根据权利要求6所述的容器故障监视方法，其特征在于，所述方法包括：监视容器首进程运行状态：当容器首进程的运行状态为非正常时，进一步判断容器状态是否为退出状态，若不为退出状态，则释放容器mount挂载点和cgroup资源并更新容器运行状态为退出，同时从周期性监视列表移除对应容器。

8.根据权利要求6或7所述的容器故障监视方法，其特征在于，进入对应容器命名空间中尝试拉起掉线的容器业务进程的步骤包括：

获取容器业务进程启动命令和参数；

根据容器业务进程启动命令和参数找到宿主机上符合条件的一组容器业务进程PID，并根据之前启动容器时记录的每个容器首进程PID获取其命名空间；

根据容器业务进程的标识定位到业务进程所在的容器并重新进入容器命名空间中主动尝试拉起对应进程，同时将当前执行命令的进程PID加入cgroup容器资源限制组中；

其中，所述标识根据容器业务进程的特征值进行分类获取；所述特征值包括容器业务进程启动命令和参数、容器业务进程PID和所属命名空间描述符。

9.根据权利要求8所述的容器故障监视方法，其特征在于，尝试拉起掉线的容器业务进程的次数设置为三次，若三次拉起容器业务进程都失败，则将该容器业务进程状态设置为失败状态。

10.一种容器恢复方法，其特征在于，所述容器运行在集群的其中一个宿主机上，所述集群中其余宿主机存放有所述容器的初始镜像；所述方法包括以下步骤：

响应于容器被配置为故障状态获取每个容器所使用的宿主机磁盘目录，并且针对每个容器在相应宿主机磁盘目录上的所有文件进行增加、删除和修改情况做增量标记；

配置时间间隔，定期将每个容器在相应宿主机磁盘目录上所有文件的增量标记进行更新，并将最新版本的文件同步到其余宿主机磁盘的文件中，同时删除同步标记；

检查还未同步完成的标记，执行同步后再使用最新的容器镜像启动容器，实现容器快速跨主机恢复。

Images