CN110377395A - 一种Kubernetes集群中的Pod迁移方法 - Google Patents

Abstract

本发明提供了一种Kubernetes集群中的Pod迁移方法，包括以下步骤：S1、Kubelet获取被执行迁移Pod所对应的Pod信息，循环地对源端中被执行迁移Pod中的容器执行Checkpoint操作，以通过checkpoint设置的断点保存当前进程并保存成镜像文件；S2、捕获被执行迁移Pod中容器的状态参数，并将镜像文件发送至目标端，以通过目标端中部署的Kubelet还原被执行迁移Pod所对应的服务，并启动服务。通过本发明所揭示的一种Kubernetes集群中Pod迁移方法，实现了对Kubernetes集群中Pod的热迁移操作，确保了被执行迁移操作的Pod向用户提供的服务在Pod迁移过程中不发生中断，从而有效地提高了用户体验。

Description

一种Kubernetes集群中的Pod迁移方法

技术领域

本发明涉及云计算技术领域，尤其涉及一种Kubernetes集群中的Pod迁移方法。

背景技术

在Kubernetes集群中，Pod是所有业务类型的基础，它是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及如何运行的规范。在Pod中，所有容器都被同一安排和调度，并运行在共享的上下文中。对于具体应用而言，Pod是它们的逻辑主机，Pod包含业务相关的多个应用容器。Kubernetes不只是支持Docker容器，它也支持其他容器。Pod的上下文可以理解成多个linux命名空间的联合：例如，PID命名空间(同一个Pod中应用可以看到其它进程)、网络命名空间(同一个Pod的中的应用对相同的IP地址和端口有权限)、IPC命名空间(同一个Pod中的应用可以通过VPC或者POSIX进行通信)或者UTS命名空间(同一个Pod中的应用共享一个主机名称)。一个Pod的共享上下文是Linux命名空间、cgroups和其它潜在隔离内容的集合。

在Pod中，容器共享一个IP地址和端口空间，它们可以通过localhost发现彼此。在同一个Pod中的容器，可以使用System V或POSIX信号进行标准的进程间通信和共享内存。在不同Pod中的容器，拥有不同的IP地址，因此不能够直接在进程间进行通信。容器间通常使用Pod IP地址进行通信。在一个Pod中的应用于口访问共享的存储卷，它被定为Pod的一部分，可以被挂接至每一个应用文件系统。

与独立的应用容器一样，Pod是一个临时的实体，它有着自己的生命周期。在Pod被创建时，会被指派一个唯一的ID，并被调度到Node中，直到Pod被终止或删除。如果Pod所在的Node宕机，给定的Pod(即通过UID定义)不会被重新调度。相反，它将被完全相同的Pod所替代。这所说的具有和Pod相关生命周期的情况，例如存储卷，是说和Pod存在的时间一样长。如果Pod被删除，即使完全相同的副本被创建，则相关存储卷等也会被删除，并会Pod创建一个新的存储卷等。Pod本身就没有打算作为持久化的实体，在调度失败、Node失败和获取其它退出(例如缺少资源或者Node在维护)情况下，Pod都会被删除。

一般来说，用户不应该直接创建Pod，即使创建单个的Pod也应该通过控制器创建。在集群范围内，控制器为Pod提供自愈能力，以及副本和部署管理。一个多容器的Pod会包含一个文件拉取器和一个web服务器，此web服务器使用一个持久化存储卷来在容器中共享存储。

当某个计算节点需要维护或者业务整合或者原有节点负载过高时，就需要将该计算节点中的Pod迁移至其他计算节点中。现有技术中对Pod迁移时必须先关闭或挂起虚拟机，然后才能开始冷迁移过程。因此，在现有技术中，Kubernetes集群中的Pod在迁移过程中势必对源端中的Pod中的一个或者多个容器为用户提供的各种服务或者进程造成非常大的影响。

有鉴于此，有必要对现有技术中的一种Kubernetes集群中的Pod迁移方法予以改进，以解决上述问题。

发明内容

本发明的目的在于揭示一种Kubernetes集群中的Pod迁移方法，用以实现在对Pod在计算节点之间进行迁移的过程中，以实现Pod迁移操作过程中不中断对外服务，以提高用户体验。

为实现上述目的，本发明提供了一种Kubernetes集群中的Pod迁移方法，包括以下步骤：

S1、Kubelet获取被执行迁移Pod所对应的Pod信息，循环地对源端中被执行迁移Pod中的容器执行Checkpoint操作，以通过checkpoint操作设置的断点保存当前进程并保存成镜像文件；

S2、捕获被执行迁移Pod中容器的状态参数，并将镜像文件发送至目标端，以通过目标端中部署的Kubelet还原被执行迁移Pod所对应的服务，并启动服务。

作为本发明的进一步改进，所述Kubelet中部署计数器，并通过计数器记录被执行迁移Pod所对应的Pod信息。

作为本发明的进一步改进，所述步骤S1还包括：使用Kubelet中部署的计数器对源端与目标端中被执行迁移Pod所对应的Pod信息进行初始化统计，并发送至调度器。

作为本发明的进一步改进，所述步骤S1中还包括：将被执行迁移的Pod所对应的Pod信息与镜像文件封装成服务集，并通过Kubernetes集群中的调度器将所述服务集发送至目标端。

作为本发明的进一步改进，所述Pod信息由Pod字段、容器数量、容器ID、容器健康状态中的一种或者几种共同描述。

作为本发明的进一步改进，所述步骤S2中还包括：通过目标端中部署的Kubelet对发送至目标端的服务集循环地执行还原操作，并启动服务。

作为本发明的进一步改进，所述步骤S1中在Kubelet获取被执行迁移Pod所对应的Pod信息之后，还包括：

将Pod字段暴露给被执行迁移Pod中所包含的容器；

所述Pod字段包括CPU限额项目与内存限额项目。

作为本发明的进一步改进，当目标端启动被执行迁移Pod所对应的服务后，还包括判断服务是否正常启动；

若是，删除目标端中被执行迁移的Pod信息；

若否，调用目标端中的计数器以判断是否达到预定计数；若是，删除源端与目标端上的服务集；若否，跳转执行目标端中部署的Kubelet对发送至目标端的服务集循环地执行还原操作。

与现有技术相比，本发明的有益效果是：通过本发明所揭示的一种Kubernetes集群中Pod迁移方法，实现了对Kubernetes集群中Pod的热迁移操作，确保了被执行迁移操作的Pod向用户提供的服务在Pod迁移过程中不发生中断，从而有效地提高了用户体验。

附图说明

图1为本发明一种Kubernetes集群中的Pod迁移方法的整体流程图；

图2为Kubernetes集群运行本发明一种Kubernetes集群中的Pod迁移方法的拓扑图；

图3为本发明一种Kubernetes集群中的Pod迁移方法的具体流程图。

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

请参图1至图3所揭示的本发明一种Kubernetes集群中Pod迁移方法(以下简称“方法”)的一种具体实施方式。

本实施例所揭示的方法可对基于Docker容器技术所组建的Kubernetes集群中，对包含一个或者多个容器的Pod在Kubernetes集群不停止向上为用户(图2所示出的Client30)提供服务的过程中，对Pod执行热迁移的迁移操作，以应对Kubernetes集群中的节点因系统维护、向上提供服务的能力无法满足用户需求或者节点负载过高等多种因素而导致需要对Pod进行迁移的场景。在本申请中节点最优选为计算节点，当然也可为存储节点；同时，本实施例所是示出的方法既可以在两个计算节点之间执行Pod的热迁移操作，也可以在计算节点与存储节点之间执行Pod的热迁移操作，也可以在两个存储节点之间执行Pod的热迁移操作。Kubernetes集群的后端存储类型既可以是HDFS，也可是Ceph存储等分布式存储系统。

Node-1中部署的Kubelet20及Node-2中部署的Kubelet21作为资源管理器，用于维持节点(Node)上运行的Pod以及提供Kuberntes运行时环境，主要完成以下使命：(1)监视分配给该Node节点的Pod；(2)挂载Pod所需要的volumes；(3)下载Pod的secret；(4)通过docker/rkt来运行Pod中的容器；(5)周期的执行Pod中为容器定义的liveness探针；(6)上报Pod的状态给系统的其他组件(例如调度器10)；(7)上报Node的状态。

参图2所述，为简化表示，本实施例中仅范例性的示出Node-1与Node-2这两个节点，并将上述两个节点与Master12构成主从关系(Master-Slave)，Master12作为主节点，其部署调度器10(Scheduler)。本实施例中所揭示的方法通过图2所揭示的Kubernetes集群予以配合说明。

该Kubernetes集群中形成Node-1与Node-2。被执行Pod迁移操作所对应的Pod11被热迁移至Node-2中后对应形成Pod11a。Pod11中配置容器_1至容器_n，参数n取正整数。Pod11或者Pod11向上为Client30提供服务。同时，在本实施例中，术语“源端”与术语“目标端”分别与图2中的Node-1与Node-2所对应，当Node-1中的Pod11执行热迁移操作并迁移至Node-2中并形成Pod11a时，则Node-1相当于“源端”，Node-2相当于“目标端”。

结合图1与图3所示，该Kubernetes集群中的Pod迁移方法，包括以下步骤：

首先，执行步骤S1、Kubelet获取被执行迁移Pod所对应的Pod信息，循环地对源端中被执行迁移Pod中的容器执行Checkpoint操作，以通过checkpoint操作设置的断点保存当前进程并保存成镜像文件。通过checkpoint操作设置的断点保存当前进程是Pod11中的容器_1至容器_n的当前进程。

Checkpoint操作可以指定把数据放在本地并且是多副本的方式，但是在正常生产环境下放在HDFS上，从而巧妙的借助HDFS高可靠的特征来完成最大化的可靠的持久化数据的方式。Checkpoint首先要调用SparkContext的setCheckpointDir()方法，设置一个容错的文件系统的目录，例如HDFS；然后，对RDD调用checkpoint()方法。之后，在RDD所处的任务运行结束之后，会启动一个单独的任务，来将Checkpoint操作处理过的RDD数据写入之前设置的文件系统，进行高可用、容错的类持久化操作。相对于传统的数据持久化技术，Checkpoint操作所产生的数据是放在HDFS中的，具有高容错性。因此，非常适合Pod在不同节点之间执行热迁移操作的场景，并确保基于Pod11向Client30提供的应用发生最小中断的情况下的Pod在不同节点之间的热迁移操作。

在本实施例中，所谓Kubelet获取被执行迁移Pod所对应的Pod信息具体为：Kubelet20获取Pod11所对应的Pod信息。Pod信息由Pod字段、容器数量、容器ID、容器健康状态中的一种或者几种共同描述。其中，Pod字段的值作为环境变量的值，通过Pod字段能够更好的描述Pod的生命周期状态。Pod字段包括：Pending(含义：系统已经接受pod实例的创建，但其中所包含容器的一个或者多个image还没有创建成功。Pending包含调度计算与通过网络创建image)；Running(含义：Pod已经被调度到某个node上，pod包含的所有容器已经创建完成，至少有一个容器正常运行或者处于启动与重启动过程)；Succeeded(含义：Pod中的所有容器正常终止，并且不会再次启动)；Failed(含义：Pod中所有容器已终止运行，至少有一个容器非正常结束，比如退出码非零，被系统强制杀死等)；Unknow(含义：无法取得pod状态，一般是网络问题引起)以及CPU限额项目与内存限额项目，Pod字段被挂载到/etc。

优选的，在本实施例中，步骤S1中在Kubelet20获取被执行迁移Pod，即Pod11所对应的Pod信息之后，还包括：将Pod字段暴露给被执行迁移Pod中所包含的容器_1至容器_n；其中，Pod字段包括CPU限额项目与内存限额项目。在Pod11中创建容器时，Pod字段在DownwardAPIVolumeFile中。Pod11有一个downwardAPI卷，并且挂载到“目录/etc/podinfo”。容器可以通过环境变量和DownwardAPIVolumeFiles获得节点的名称、容器的名称、Pod的Namespace、Pod的IP地址、CPU限额项目与内存的限额项目。如果容器没有指定CPU和内存的限额项目，Downward API默认的值是节点可分配的CPU和内存。通过将Pod字段暴露给被执行迁移Pod中所包含的容器_1至容器_n，使得容器_1至容器_n在运行时能读到这些Pod字段，并能够使得运行中的容器_1至容器_n可以不用通过与Kubernetes集群中的Master12进行交互，从而降低了Kubernetes集群中的主从节点之间数据传输量，提高了整个Kubernetes集群的性能；更为重要的是，在Pod11从Node-1执行热迁移的操作并迁移至Node-2以形成Pod11a的过程中，可通过访问“目录/etc/podinfo”直接获取被执行迁移操作的Pod11所对应的Pod字段，Pod字段运行在yaml文件中，从而非常有利于降低Node-2中的Kubelet21对迁移至Node-2中的Pod11a的描述难度，并避免Master12对迁移至Node-2中的Pod11a重复执行描述的事件。当Pod11被迁移至Node-2中并形成Pod11a时，Client30可直接访问Pod11a，并由Pod11a对Client30发起的请求予以响应。通过上述技术方案，可有效地降低了Kubernetes集群中逻辑上位于底层的节点的维护管理成本，当Master12中所部署的Controller manager(未示出)检测到Node-1需要暂停服务进行维护时，可将Node-1中的Pod11迁移至健康的Node-2中。同时，本实施例所揭示的方法，在Pod11迁移至Node-2的过程中，可配合节点间的负载均衡策略，将Node-1中Pod11迁移至Node-2中。需要说明的是，迁移至Node-2仅仅是一个范例性的场景，在真实场景中，作为从节点Node可以是两个、三个、四个或者更多数量的Node；并且，Pod11迁移至Node-2也可以是由于Node-2的负载相对于除了Node-1之外的其他节点而言负载较低的因素。

同时，在本实施例中，步骤S1还包括：使用Kubelet20中部署的计数器201对源端(即Node-1)与目标端(即Node-2)中被执行迁移Pod所对应的Pod信息进行初始化统计，并发送至调度器10。从而防止出现被执行迁移操作的Pod在执行迁移后该Pod所包含的容器的数量在迁移操作前后不一致的情形。Kubelet20中部署计数器201，并通过计数器201记录被执行迁移Pod所对应的Pod信息。同时，Node-2中的Kubelet21中也部署有相同的计数器(未示出)。该步骤S1还包括将被执行迁移的Pod所对应的Pod信息与镜像文件111封装成服务集，并通过Kubernetes集群中的调度器10将所述服务集发送至目标端(即Node-2)。

Kubelet20与Kubelet21均集成CRIU(Checkpoint/Restore in Userspace)的checkpoint功能，并集成CRIU的还原功能，以在Pod11被热迁移至Node-2中执行还原操作。在本实施例中，通过在Kubelet20及Kubelet21中集成Checkpoint操作的功能，可对Pod11或者Pod11a所形成的应用或者服务的进程树和地址空间创建检查点，此时Node-1中的容器_1至容器_n的状态被保持成镜像文件111(iso)。在本实施例中，通过checkpoint操作实现了以下技术效果：(1)缩短数据库的恢复时间；(2)缓冲池不够用时，将脏页(dirty page)刷新到磁盘；(3)重做系统日志不可用时，刷新脏页。具体而言，当数据库发生宕机时，数据库不需要重做所有的系统日志，因为Checkpoint之前的页都已经刷新回磁盘。数据库只需对Checkpoint后的重做系统日志进行恢复，这样就大大缩短了恢复的时间。当缓冲池不够用时，根据LRU算法会溢出最近最少使用的页，若此页为脏页，那么需要强制执行Checkpoint，将脏页也就是页的新版本刷回磁盘。当重做日志出现不可用时，因为当前事务数据库系统对重做日志的设计都是循环使用的，并不是让其无限增大的，重做日志可以被重用的部分是指这些重做日志已经不再需要，当数据库发生宕机时，数据库恢复操作不需要这部分的重做日志，因此这部分就可以被覆盖重用。如果重做日志还需要使用，那么必须强制Checkpoint操作，将缓冲池中的页至少刷新到当前重做日志的位置。由此可显著地降低Kubernetes集群中系统日志的所占用的磁盘空间。

然后，执行步骤S2、捕获被执行迁移Pod中容器的状态参数，并将镜像文件111发送至目标端(即node-2)，以通过目标端中部署的Kubelet21还原被执行迁移Pod所对应的服务，并启动服务。Kubelet21同样集成CRIU(Checkpoint/Restore in Userspace)的checkpoint功能，并集成CRIU的还原功能，以在Pod11被热迁移至Node-2中执行还原操作。

具体的，在本实施例中，步骤S2中还包括：通过目标端中部署的Kubelet21对发送至目标端的服务集循环地执行还原操作，并启动服务。具体的，当目标端启动被执行迁移Pod所对应的服务后，还包括判断服务是否正常启动；

若是，删除目标端(即Node-2)中被执行迁移的Pod信息，此时Node-1中的Pod11所对应的Pod信息被删除，以降低Node-1中的数据冗余。

若否，调用目标端(node-2)中的计数器以判断是否达到预定计数；若是，删除源端(node-1)与目标端(node-2)上的服务集；若否，跳转执行目标端(node-2)中部署的Kubelet21对发送至目标端(node-2)的服务集循环地执行还原操作(Restore)，从而保证被执行热迁移操作的Pod11在被热迁移至Node-2中的一致性。

目标端(即Node-2)中的计数器以判断是否达到预定计数可基于步骤S1中已经发送至调度器10中且通过源端(即Node-1)计数器201对执行热迁移操作前的Pod11所执行的Pod信息进行初始化统计操作加以确定。本实施例中步骤S1与步骤S2的具体实现过程请参图3所示。

综上，通过本实施例所揭示的方法，实现了对Kubernetes集群中Pod的热迁移操作，确保了被执行迁移操作的Pod向用户提供的服务在Pod迁移过程中对Client30所提供的服务或者应用不发生中断，从而有效地提高了用户体验。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (8)

1.一种Kubernetes集群中的Pod迁移方法，其特征在于，包括以下步骤：

S1、Kubelet获取被执行迁移Pod所对应的Pod信息，循环地对源端中被执行迁移Pod中的容器执行Checkpoint操作，以通过checkpoint操作设置的断点保存当前进程并保存成镜像文件；

S2、捕获被执行迁移Pod中容器的状态参数，并将镜像文件发送至目标端，以通过目标端中部署的Kubelet还原被执行迁移Pod所对应的服务，并启动服务。

2.根据权利要求1所述的Pod迁移方法，其特征在于，所述Kubelet中部署计数器，并通过计数器记录被执行迁移Pod所对应的Pod信息。

3.根据权利要求2所述的Pod迁移方法，其特征在于，所述步骤S1还包括：使用Kubelet中部署的计数器对源端与目标端中被执行迁移Pod所对应的Pod信息进行初始化统计，并发送至调度器。

4.根据权利要求1所述的Pod迁移方法，其特征在于，所述步骤S1中还包括：将被执行迁移的Pod所对应的Pod信息与镜像文件封装成服务集，并通过Kubernetes集群中的调度器将所述服务集发送至目标端。

5.根据权利要求1至4中任一项所述的Pod迁移方法，其特征在于，所述Pod信息由Pod字段、容器数量、容器ID、容器健康状态中的一种或者几种共同描述。

6.根据权利要求4所述的Pod迁移方法，其特征在于，所述步骤S2中还包括：通过目标端中部署的Kubelet对发送至目标端的服务集循环地执行还原操作，并启动服务。

7.根据权利要求5所述的Pod迁移方法，其特征在于，所述步骤S1中在Kubelet获取被执行迁移Pod所对应的Pod信息之后，还包括：

将Pod字段暴露给被执行迁移Pod中所包含的容器；

所述Pod字段包括CPU限额项目与内存限额项目。

8.根据权利要求7所述的Pod迁移方法，其特征在于，当目标端启动被执行迁移Pod所对应的服务后，还包括判断服务是否正常启动；

若是，删除目标端中被执行迁移的Pod信息；

若否，调用目标端中的计数器以判断是否达到预定计数；若是，删除源端与目标端上的服务集；若否，跳转执行目标端中部署的Kubelet对发送至目标端的服务集循环地执行还原操作。