一种节点故障避免场景下的容器服务热迁移平台及方法

本发明属于容器服务热迁移，尤其是涉及一种节点故障避免场景下的容器服务热迁移平台及方法。

背景技术：

1、在kubernetes环境下部署有状态服务主要使用statefulset资源对象，该对象使用替换机制进行失效pod的管理，在一定程度上提供了自动修复的能力，但在保证有状态服务的高可用上还存在一定局限性：

2、①有状态服务在使用statefulset资源对象管理其服务实例时，pod的重调度保留了持久化数据与网络拓扑信息。然而，这种机制所保留的信息并不包含pod内容器应用的运行时信息。根据分布式软件的cap理论，这会让满足cp特性的pod应用重新创建后经历长时间的初始化阶段，或者引起满足ap特性的pod应用的未落盘数据丢失，带来极大的弊端。避免这个问题需要pod本身尽量无状态化，对有状态服务的设计会有一定要求。所以，pod进行重调度时需要关注容器运行时状态的恢复。

3、②由于pod集合中的每个pod使用了属于自己的pv，拥有独立的持久化数据，并且拥有唯一的dns解析记录，因此具备一定的特殊性。这意味着复本集中的每个pod不一定是完全对等的关系。当某个pod失效时，其它pod不能无缝的接替它，而是必须等待失效pod被调度重启，这会导致较长时间的降级或服务中断。

4、③当kubernetes集群的节点因为断电、故障等极端情况而意外关闭时，有状态应用不会在其它健康节点上被重新调度创建，而是将一直停留在关闭的节点上。这是因为节点的非正常关闭导致kubelet没有检测到节点的关闭事件，最终导致该节点上的pod没有被终止并释放资源。kubernetes无法判断节点会在何时恢复重新加入集群，在这个不确定性事件中，statefulset资源对象为了防止拥有相同身份的多个pod同时存在而引起冲突，故不会创建新pod来接替无响应节点上的pod。尽管在最新方案中可以人为地为无响应节点设置停用污点以强制删除资源，但这需要管理人员的介入，如果管理人员未及时介入，服务可用性将得不到保障。

5、有状态迁移机制将容器应用运行时状态的有关信息进行复制保存，形成存档文件，随后在另一节点读取存档文件并在系统中还原这些信息，重新启动后的容器应用拥有迁移前的信息与资源，故应用的连续性得到了保障，目前主要使用checkpoint/restore技术。checkpoint/restore技术在虚拟机上得到了广泛使用，近年来将其运用到容器的研究也逐渐增多。然而，将这套机制运用在kubernetes中的研究较少，最主要的原因是这与kubernetes的容器管理理念是冲突的，具体为：首先，kubernetes使用pod作为最小调度单位管理容器，并且希望容器尽量无状态化，使得容器运行失败时在另一节点可以快速重启。这意味着容器的生命周期是不希望被外部组件影响的，而使用checkpoint/restore技术进行有状态迁移破坏了容器的生命周期，它会使容器增加一个“迁移中”的阶段。同时，增加的生命周期阶段将不被复本集资源对象(如deployment、statefulset等)所兼容，这将导致pod在kubernetes集群中的配置状态丢失甚至引起冲突；其次有状态的迁移机制会涉及更多数据的迁移，尽管其保证了程序运行的连续性，但在时间连续性上未必比无状态迁移机制更优秀。

技术实现思路

1、本发明的目的是提供一种节点故障避免场景下的容器服务热迁移平台及方法，解决现有技术存在的kubernetes环境下的有状态服务可用性差且在动态迁移时pod的生命周期易被破坏的问题。

2、为实现上述目的，本发明提供了一种节点故障避免场景下的容器服务热迁移平台，容器服务热迁移平台基于kubernetes集群，包括master节点和node节点，master节点包括migss控制器和迁移控制器，node节点包括源工作节点和目标工作节点，源工作节点和目标工作节点均包括扩展的kubelet和迁移执行器；

3、migss控制器负责对源pod与克隆pod分配不同的管理策略；

4、迁移控制器负责有状态迁移的总体控制；

5、扩展的kubelet具备容器状态存档功能；

6、迁移执行器被迁移控制器管理，负责状态存档文件传输、接收以及建立有状态镜像，并在同步阶段控制源pod与克隆pod增量状态同步。

7、优选的，当迁移控制器接收来自节点故障预测组件或人为的迁移命令后，获取需要迁移的pod列表，触发迁移工作，迁移控制器通知源工作节点上的kubelet对待迁移pod进行状态存档，完成后源pod继续对外提供服务。

8、优选的，迁移执行器是一个守护进程，每个工作节点上均存在，源工作节点的迁移执行器将状态存档文件传输至目标工作节点，目标工作节点的迁移执行器使用存档文件建立有状态镜像，之后系统启动克隆pod。

9、优选的，migss控制器的控制逻辑中有两个pod组，分别为正式组标记正常使用的pod和备用组标记克隆的pod；克隆的pod被控制器软管理，对克隆的pod进行捕获、为其添加ownerreference并纳入控制器管理，但不列入控制循环中，也不配置网络资源，因此克隆pod在微服务架构中是透明的，当正式组标记正常使用的某个pod为空时，migss控制器先检测是否能在备用组找到对应的克隆pod，如果存在，将克隆pod替换源pod而不进行重新调度创建，同时为克隆pod配置网络资源，克隆pod以源pod的身份在微服务架构中继续提供服务。

10、本发明还提供了一种节点故障避免场景下的容器服务热迁移平台的方法，包括迁移准备阶段和批量迁移阶段；迁移准备阶段具体为目标工作节点的选择与基础镜像的预拉取；批量迁移阶段具体为网络感知的批量迁移。

11、优选的，迁移准备阶段中目标工作节点的选择与基础镜像的预拉取的具体过程如下：

12、步骤1、迁移控制器获取源工作节点上待迁移的pod信息，形成预迁移队列，判断预迁移队列是否为空，若为空则结束；否则执行步骤2；

13、步骤2、取出队头pod信息，该队头pod信息包含pod内容器的基础镜像的镜像层集合；

14、步骤3、计算基础镜像与候选节点的镜像层相似度，其中候选节点集合来自kubernetes集群的默认调度器的预选节点集合；

15、步骤4、重复步骤3，判断候选节点集合是否全部遍历，若否，则继续执行步骤3，否则删除相似度低于目标相似度的目标工作节点，并对剩余节点按相似度进行排序，得到目标工作节点，拉取镜像；

16、步骤5、重复步骤2、3、4，直至预迁移队列为空。

17、优选的，步骤3中基础镜像与候选节点的镜像层相似度的计算过程如下：

18、s31a、将一个基础镜像视为一组镜像层堆叠打包后的集合b，,，其中每一个镜像层都有唯一的哈希id，设候选节点集合为，表示第i个候选节点上所有镜像层集合，，b与之间的差异程度对基础镜像的拉取的开销有影响，设镜像层集合中的某一镜像层layer与镜像层的包含关系为：

19、；

20、s32a、通过s31a中的包含关系得到向量和的表示：

21、；

22、；

23、s33a、计算b与之间的相似度，计算表达式如下：

24、。

25、优选的，批量迁移阶段中网络感知的批量迁移的过程如下：

26、s1、获取迁移队列，已进行基础镜像预拉取的pod被加入到迁移队列中；

27、s2、取出队头pod信息，判断传输集合是否为空，当传输列表为空时，直接进行状态存档的传输，加入传输集合，否则进入s3；

28、s3、在传输当前pod的存档文件之前，先计算网络带宽资源和传输时间，判断容器批量k增加1是否会引起传输中的文件超时，若超时，则放回迁移队列中，返回执行s2，否则判断该存档在获得的网络带宽资源情况下是否超时，若超时，则放回迁移队列中，返回执行s2，否则加入传输集合；

29、s4、在s3的两个指标均不超时的情况下，将状态存档加入传输集合中；

30、s5、重复s2、s3、s4，直至迁移队列为空。

31、优选的，计算带宽资源和传输时间，判断是否可以加入传输集合的具体过程如下：

32、s31b、设每个容器快照文件的大小为，在迁移过程中，源主机的总带宽资源 n是均匀分配给并行迁移的容器，容器批量为k，那么每个容器在迁移过程中使用的网络带宽资源为：

33、；

34、s32b、计算传输存档文件需要的时间，计算表达式如下：

35、；

36、式中，为已经传输的数据，为目前已经花费的时间；

37、s33b、设置约束，具体为确保所有快照文件的迁移时间在内完成，保证最慢的批次迁移时间满足总时间限制，计算表达式如下：

38、；

39、s34b、迁移批量大小满足下式：

40、；

41、式中，为现阶段容器快照文件数据大小中的最大值。

42、因此，本发明采用上述一种节点故障避免场景下的容器服务热迁移平台及方法，具有以下有益效果：

43、（1）在kubernetes环境下实现了容器应用的有状态迁移，在实际操作中，使用“克隆”替代了“迁移”，保护了容器的生命周期；

44、（2）设计了资源对象migss及其控制器，将应用的有状态迁移能力与有状态服务副本集管理能力进行整合，相较于基于替换机制的statefulset资源对象，本方案实现全方位的状态迁移与恢复；

45、（3）在应用的有状态迁移基础上使用日志回放机制实现了应用的动态迁移，以缩短迁移引起的停机时间；

46、（4）本发明支持在服务器故障避免下的主动迁移机制，因此使用了相似度过滤机制优化了基础镜像的拉取流程，并且支持pod的批量并行迁移，以缩短总的迁移时间，提高服务可用性保障。

47、下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。