CN118093090A - 一种应用迁移方法、***、设备及介质 - Google Patents

Abstract

本申请公开了一种应用迁移方法、***、设备及介质，用以当应用在源节点不可用时，实现将该应用迁移到目的节点上，使其可以在目的节点上正常运行，使得该应用可以继续为用户提供服务。本申请提供的方法包括：确定需要将源节点的目标应用迁移到目的节点；将目标应用所关联的PVC解绑，并且为PVC设置迁移标签，用于指示应用编排管理***的控制器不对设置有迁移标签的PVC进行绑定；删除目标应用的源PV与PVC的绑定关系；驱逐源节点上的目标应用的容器Pod，触发应用编排管理***的调度器将Pod重新调度到目的节点上；通过CSI组件将目标应用的源PV数据迁移到目的节点上，并创建目的PV，以及删除PVC的迁移标签；通过控制器建立目的PV与PVC的绑定关系。

Description

一种应用迁移方法、***、设备及介质

技术领域

本申请涉及容器云技术领域，尤其涉及一种应用迁移方法、***、设备及介质。

背景技术

容器技术作为云原生领域的新兴虚拟化技术，在云计算和容器云领域中扮演着重要的角色。它的兴起催生了一系列应用编排管理***，其中包括Kubernetes(简称K8S)、Docker Swarm和Mesosphere等。在这些***中，Kubernetes凭借其强大的应用编排能力和智能化调度算法成为容器编排领域的领导者。调度器(Scheduler)作为Kubernetes的核心组件，负责将编排的应用程序调度到适合的节点上，并进行资源分配。在调度过程中，调度器会考虑节点的可用资源、约束条件和健康状态等因素，以确保应用程序能够得到有效的部署和运行。

发明内容

本申请实施例提供了一种应用迁移方法、***、设备及介质，用以当应用在源节点不可用时，实现将该应用迁移到目的节点上，使其可以在目的节点上正常运行，使得该应用可以继续为用户提供服务。

本申请实施例提供的一种应用迁移方法，包括：

确定需要将源节点的目标应用迁移到目的节点；

将所述目标应用所关联的持久化卷声明PVC解绑，并且为所述PVC设置迁移标签，用于指示应用编排管理***的控制器不对设置有所述迁移标签的PVC进行绑定；

删除所述目标应用的源持久化卷PV与所述PVC的绑定关系；

驱逐所述源节点上的所述目标应用的容器Pod，触发所述应用编排管理***的调度器将所述Pod重新调度到目的节点上；

通过容器存储接口CSI组件将所述目标应用的源PV数据迁移到所述目的节点上，并创建目的PV，以及删除所述PVC的迁移标签；

通过所述控制器建立所述目的PV与所述PVC的绑定关系。

由此可见，本申请实施例，可以针对资源不足、反亲和性以及卷信息变更等，导致的目标应用在源节点不可用的情况，实现将该目标应用迁移到目的节点上，使该目标应用可以在目的节点上正常运行，避免该目标应用无法为用户提供服务的问题，使得该目标应用可以在目的节点上继续为用户提供服务。

在一些实施例中，通过容器存储接口CSI组件将所述目标应用的源PV数据迁移到所述目的节点上，包括：

当所述CSI组件监控到设置有所述迁移标签的PVC时，通过创建工作流任务，将所述目标应用的源PV数据迁移到所述目的节点上；其中，所述创建工作流任务包括在所述源节点创建客户端Pod，以及在所述目的节点创建服务端Pod，所述客户端Pod用于从所述源节点的第一路径获取所述源PV数据并发送给所述服务端Pod，所述服务端Pod用于接收所述客户端Pod发送的所述源PV数据，并存储到所述目的节点的第二路径。

在一些实施例中，所述客户端Pod，通过启动远程数据同步进程，从所述源节点的第一路径获取所述源PV数据并发送给所述服务端Pod。

在一些实施例中，所述方法还包括：

通过所述客户端Pod周期性地获取数据传输进度；

当基于所述数据传输进度，确定所述客户端Pod传输数据完毕时，设置所述工作流任务为成功状态。

在一些实施例中，所述方法还包括：

当发生所述客户端Pod与所述服务端Pod之间的数据传输中断的异常情况时，通过所述客户端Pod获取异常原因，并重新启动所述客户端Pod从所述源节点的第一路径获取所述源PV数据并发送给所述服务端Pod，其中，当所述客户端Pod重启次数超过预设次数时，标记所述工作流任务为失败状态并通知用户。

在一些实施例中，所述确定需要将源节点的目标应用迁移到目的节点，包括：

通过设置在所述应用编排管理***的调度器中的预设第一调度插件，监控到满足如下条件之一或组合时，确定需要将源节点的目标应用迁移到目的节点：

所述源节点的CPU被所述目标应用之外的其他应用占用，并且，所述源节点没有可以驱逐的无状态应用；

所述目标应用重新上线后，所述源节点上的原有应用与所述重新上线的目标应用具有反亲和性；

所述目标应用重新上线后，所述目标应用所关联的PVC的卷信息发生变更。

在一些实施例中，所述方法还包括：

当所述源节点的CPU被所述目标应用之外的其他应用占用时，驱逐所述源节点上的无状态应用，直到所述源节点的CPU满足运行所述目标应用的条件。

在一些实施例中，所述方法还包括：

通过设置在所述应用编排管理***的调度器中的预设第二调度插件，监控所述目标应用所关联的PVC处于非绑定状态的时长，当所述时长超过预设值时，触发对所述PVC的重新绑定操作。

相应地，本申请实施例提供的一种应用迁移***，包括：调度器组件、重调度组件、CSI组件、控制器组件；其中，

所述调度器组件，用于确定需要将源节点的目标应用迁移到目的节点；以及，在所述重调度组件的触发下，将所述Pod重新调度到目的节点上；

所述重调度组件，用于：

将所述目标应用所关联的持久化卷声明PVC解绑，并且为所述PVC设置迁移标签，用于指示所述控制器组件不对设置有所述迁移标签的PVC进行绑定；

删除所述目标应用的源持久化卷PV与所述PVC的绑定关系；

驱逐所述源节点上的所述目标应用的容器Pod，触发所述调度器组件将所述Pod重新调度到目的节点上；

所述CSI组件，用于将所述目标应用的源PV数据迁移到所述目的节点上，并创建目的PV，以及删除所述PVC的迁移标签；

所述控制器组件，用于建立所述目的PV与所述PVC的绑定关系。

本申请另一实施例提供了一种电子设备，其包括存储器和处理器，其中，所述存储器用于存储程序指令，所述处理器用于调用所述存储器中存储的程序指令，按照获得的程序执行上述任一种方法。

本申请另一实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使所述计算机执行上述任一种方法。

附图说明

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

图1为本申请实施例提供的应用迁移原理示意图；

图2为本申请实施例提供的一种应用迁移方法的具体流程示意图；

图3为本申请实施例提供的数据迁移原理示意图；

图4为本申请实施例提供的一种应用迁移方法的总体流程示意图；

图5为本申请实施例提供的一种电子设备的结构示意图；

图6为本申请实施例提供的一种应用迁移***的结构示意图。

具体实施方式

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

本申请实施例提供了一种应用迁移方法、***、设备及介质，用以当应用在源节点不可用时，实现将该应用迁移到目的节点上，使其可以在目的节点上正常运行，使得该应用可以继续为用户提供服务。

其中，方法和***、设备、介质是基于同一申请构思的，由于方法和***、设备、介质解决问题的原理相似，因此***、设备、介质和方法的实施可以相互参见，重复之处不再赘述。

本申请实施例的说明书和权利要求书及上述附图中的术语“第一”、“第二”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

以下示例和实施例将只被理解为是说明性的示例。虽然本说明书可能在若干处提及“一”、“一个”或“一些”示例或实施例，但这并非意味着每个这种提及都与相同的示例或实施例有关，也并非意味着该特征仅适用于单个示例或实施例。不同实施例的单个特征也可以被组合以提供其他实施例。此外，如“包括”和“包含”的术语应被理解为并不将所描述的实施例限制为仅由已提及的那些特征组成；这种示例和实施例还可以包含并未具体提及的特征、结构、单元、模块等。

下面结合说明书附图对本申请各个实施例进行详细描述。需要说明的是，本申请实施例的展示顺序仅代表实施例的先后顺序，并不代表实施例所提供的技术方案的优劣。

有状态应用(即stateful应用)，是指使用本地磁盘或网络磁盘进行存储的应用程序。相比网络磁盘，本地磁盘具有更高的性能，因为它不受网络传输的影响。然而，由于本地磁盘无法迁移，因此会限制应用程序只能一直在当前节点上运行。针对有状态应用，Kubernetes提供了StatefulSet这一特殊的控制器。StatefulSet允许用户定义有状态应用的部署和管理方式，并为每个实例分配独特的标识符。这样，即使在节点迁移或故障转移的情况下，应用程序也能够保持其标识和状态的一致性。因此，通过Kubernetes的调度器Scheduler和控制器StatefulSet，用户可以在容器环境中灵活管理和调度有状态应用，充分利用本地磁盘的高性能特性，并保证应用程序的稳定性和可靠性。

虽然将有状态应用部署在本地磁盘，相比网络磁盘有更高的性能，但是本地磁盘依赖于节点，当节点出现资源不足时，本地磁盘的有状态应用无法发生迁移，会导致该应用不可用。

本申请实施例提供了一种应用迁移方法，能够针对资源不足、反亲和性以及卷信息变更等，导致应用挂起(Pending)的现象，自动迁移应用，使应用运行在其他节点上；并且，能够在节点清空(drain)后，自动迁移本节点上的有状态应用。在本申请实施例提供的应用迁移过程中，可以将卷数据从源节点拷贝到目的节点，并保证数据的一致性。

参见图1，本申请实施例提供的用于实现源节点到目的节点的有状态应用迁移的组件(设置在服务端的功能模块)，包括cube-descheduler(重调度)、kube-scheduler(调度器)、kube-controller(控制器)等组件。这些组件可以设置在任何一个节点，即可以是源节点，也可以是目的节点；并且，这些组件可以设置在同一节点，也可以设置在不同节点，本申请实施例中不进行限制。其中，所述的源节点和目的节点，可以是同一物理节点，也可以是不同的物理节点。

有状态应用的迁移过程，包括有状态应用的Pod的重调度过程，以及有状态应用的数据迁移过程。其中，如图1所示，所述有状态应用的Pod的重调度过程，即在上述组件的控制下，实现将有状态应用的Pod，从源节点调度到目的节点中；所述的有状态应用的数据迁移过程，即实现有状态应用的数据从源节点中的源PV迁移到目的节点中的目的PV。

其中，cube-descheduler是核心组件，其主要功能如下：

1)、监控有状态应用的Pod的生命周期，针对资源不足、Pod亲和性以及本地卷信息变更等情况，如果导致Pod再次上线后出现Pending状态，cube-descheduler负责解绑相关卷，以便后续让Kubernetes调度器重新分配资源。其中，Pod是在Kubernetes中创建和管理的最小可部署单元，Pod是一组(一个或多个)容器的打包，这一组容器共享存储、网络；Pod中的容器地位均等且一同调度。

2)、能够处理节点排空(Drain)操作，特别是涉及到迁移本地磁盘的相关有状态应用时，cube-descheduler负责协调这一过程。

除了cube-descheduler，还有其他的Kubernetes组件参与交互，这些组件包括kube-scheduler、kube-controller等。kube-scheduler负责将Pod分配到目的节点上，而kube-controller则负责监控和管理集群中的各种资源和对象。

为了适配有状态应用的迁移，本申请实施例在kube-scheduler中引入了两个调度插件，分别为第一调度插件和第二调度插件，分别处理卷信息变更和卷超时绑定的问题。具体地：

第一调度插件，负责处理卷信息变更。当有状态应用的卷信息发生变化时，例如存储介质、存储大小等发生变化，第一调度插件会监测这些变化，并在必要时触发相应的操作，例如解绑旧卷、绑定新卷，并确保有状态应用能够正确访问更新后的卷，这样可以保证有状态应用在迁移后能够正常运行。

第二调度插件，负责处理卷超时绑定的问题。在有状态应用迁移的过程中，可能会出现卷绑定超时的情况。为了解决这个问题，第二调度插件会监测卷绑定的状态，并在超时时触发重新绑定操作，以确保有状态应用能够顺利迁移并继续运行。

也就是说，本申请实施例中通过kube-scheduler中的第一调度插件，实现应用迁移触发条件的判断，当发现满足应用迁移触发条件时，触发执行应用迁移流程。

进一步，可以通过所述第二调度插件监控有状态应用迁移过程中，该有状态应用关联的PVC解绑后处于非绑定状态的时长是否超过预设值，若超过，则触发重新绑定操作，从而使得有状态应用关联的PVC能够尽快重新绑定，以实现应用的顺利迁移并运行。

此外，CSI(Container Storage Interface，容器存储接口)组件也是参与交互的一个组件。CSI是一种标准化的接口，用于与存储***进行交互。通过CSI，Kubernetes可以与不同的存储后端进行集成和通信，以实现对存储资源的管理和操作。CSI组件的功能主要用于将迁移之前的本地卷里面的数据，复制到新的存储路径中，并根据新的存储路径，创建新的数据卷，因此，本申请实施例中将CSI组件具体称为本地路径CSI组件，表述为localpath-csi。这样可以保证有状态应用在迁移后仍能访问其原始拷贝数据，并实现数据的平滑迁移。

整体而言，本申请实施例通过上述各个组件的协同工作，实现对有状态应用的Pod的生命周期监控、资源重新调度和PV数据的迁移存储管理等，以提高存储集群的资源利用率和弹性，并确保有状态应用的稳定性和可靠性。

下面举例说明应用迁移的具体实现流程。

当本地磁盘的有状态应用发生升级或者扩容时，该有状态应用会重新上线，可能会因为环境条件不满足等原因，导致有状态应用始终处于Pending状态。其中，所述环境条件不满足，例如：CPU或者内存不满足、亲和性不满足、本地磁盘大小或者介质发生变更等等。

下面列举出有状态应用迁移的三种场景(也即三种触发条件)。

场景一、有状态应用原先运行在A节点，再次上线后，A节点CPU被其他应用占用，cube-descheduler监控到这种情况后，就会优先驱逐A节点上的无状态应用，有状态应用就会正常在A节点运行。如果A节点没有可以驱逐的无状态应用，就会发生有状态应用本身的迁移，cube-descheduler组件就会把A节点上的存储了该有状态应用的所有的本地磁盘解绑(如图1所示的PVC和原PV之间解绑)，使这些本地磁盘的PVC成为Pending状态；其中，PVC(Persistent Volume Claim)，即对PV的声明，表示需要什么类型的PV(PersistentVolume，即持久化卷，是Kubernetes管理员设置的存储)。

场景二、有状态应用原先运行在A节点，再次上线后，A节点上的服务(即应用)与当前有状态应用有反亲和，cube-descheduler监控到后，会把有状态应用驱逐，具体处理流程同场景一，此处不再赘述；

场景三、有状态应用原先运行在A节点，再次上线后，有状态应用关联的本地磁盘PVC卷信息发生变更，例如卷发生大小的变更，或者是磁盘的介质发生变更，cube-descheduler会把有状态应用驱逐，触发有状态应用的迁移操作。

也就是说，本申请实施例中通过上述第一调度插件，判断是否满足上述三种场景之一或组合，当发现满足时，即满足应用迁移触发条件时，触发执行图2所示的应用迁移流程。

参见图2，在一些实施例中，有状态应用的迁移方法，涉及如下组件之间的交互流程：cube-descheduler、kube-apiserver、kube-scheduler、kube-controller中的PV控制器(pv-controller)、CSI(本申请实施例中描述为本地路径CSI，即localpath-csi)、helm-controller。

其中，localpath-csi部署在每一节点中，图2中所示的localpath-csi为目的节点中的localpath-csi。其他组件，可以部署在K8S的主节点中。

kube-apiserver负责记录有状态应用所关联的PVC的相关信息，例如包括PVC的标签(例如migrate标签)、PVC的状态(绑定、非绑定)、PVC关联的PV的状态(可用、不可用)、PVC的Pod所在的磁盘、节点等存储信息。

kube-scheduler、pv-controller、localpath-csi，实时监控kube-apiserver，从而获得有状态应用所关联的PVC的相关信息，并进行控制更新等。

具体的应用迁移流程例如包括：

步骤1、cube-descheduler组件把需要从源节点迁移到目的节点的有状态应用(简称目标应用)所关联的PVC卷全部解绑，并给这些PVC打上迁移标签(例如migrate标签)，表示这些PVC需要进行迁移，即从源节点迁移到目的节点，并通知kube-apiserver组件，使得kube-apiserver组件记录目标应用的PVC具有迁移标签。

其中，源节点和目的节点，可以是同一物理节点，也可以是不同的物理节点。

步骤2、当pv-controller监控到kube-apiserver组件记录的目标应用的PVC具有迁移标签时，直接过滤该PVC，即pv-controller不对具有迁移标签的PVC进行绑定，从而避免该PVC的Pod未经重新调度，而直接再次与PV进行绑定。

步骤3、cube-descheduler组件控制kube-apiserver组件删除目标应用的源PV与PVC的绑定关系；

其中，所述源PV，即目标应用在源节点中的PV。相应地，目标应用在目的节点中的PV，称为目的PV。

步骤4、kube-apiserver组件删除目标应用的源PV与PVC的绑定关系后，将目标应用的源PV的状态更新为可用(Avaliable)状态，将目标应用的PVC状态更新为非绑定状态，即挂起(Pending)状态。

步骤5、cube-descheduler组件控制kube-apiserver组件驱逐目标应用的Pod，从而触发对该目标应用的Pod进行重新调度，即从源节点调度到目的节点。

步骤6、kube-scheduler组件监控到kube-apiserver组件将目标应用的Pod的状态更新为Pending；

步骤7、kube-scheduler组件将目标应用的Pod调度到目的节点上。

步骤8、kube-scheduler组件选中目的节点以及目的节点上用于存储目的PV的磁盘后，将目的节点的信息以及目的节点的用于存储目的PV的磁盘信息，更新到kube-apiserver记录的目标应用的PVC的注解(annotation)中。

步骤9、localpath-csi组件监控到目标应用的PV迁移任务，从而开始对目标应用的源PV中的数据进行迁移；

其中，localpath-csi组件监控到目标应用的PV迁移任务，即监控到kube-apiserver记录的目标应用的PVC的注解(annotation)中，更新了目的节点的信息以及目的节点的用于存储目的PV的磁盘信息。

步骤10、localpath-csi组件向helm-controller组件发送创建工作流记录(workflowrecord)请求。

其中，所述workflowrecord主要的功能就是把源节点的源PV中的数据，例如通过lsyncd(remote synchronize，远程数据同步)技术，拷贝到目的节点的存储路径下，等数据拷贝完毕后，会创建一个新的PV，即目的PV，该目的PV对应于该目的节点的存储路径，相当于目标应用的数据从源PV转移到了目的PV。

lsyncd是一个实时文件同步工具，可以自动监测文件变化并快速同步更新。通过使用lsyncd，数据的传输可以及时地进行，减少传输延迟和数据丢失的风险。

步骤11、helm-controller组件监控到localpath-csi组件发送的创建工作流记录(workflowrecord)请求后，若通过该请求(即请求通过，可以创建工作流记录)，则localpath-csi组件会创建工作流(workflow)，即创建两个任务Pod，参见图3，一个是源节点中的客户端(client)Pod，另一个是目的节点中的服务端(server)Pod；其中客户端Pod负责从源节点的路径1获取数据并投递数据给服务端Pod，服务端Pod负责接收客户端Pod发送的数据，并存储到目的节点的路径2，其中，路径1表示源PV的存储路径，路径2表示目的PV的存储路径。源PV通过目录映射，建立与路径1的关联关系；目的PV通过目录映射，建立与路径2的关联关系。

步骤12、目标应用的数据迁移完成后，localpath-csi组件上报工作流记录执行成功通知给kube-apiserver组件，并控制kube-apiserver组件为目标应用建立新的PV(即目的PV)，以及删除目标应用的PVC的迁移标签。

步骤13、pv-controller组件监控到kube-apiserver组件记录的目标应用的新的PV(即目的PV)，以及目标应用的PVC的迁移标签已删除，则控制kube-apiserver组件建立该新的PV与该PVC的绑定关系，此时目标应用的PVC状态为绑定状态。

步骤14、pv-controller组件通知kube-scheduler组件，目标应用的PVC与目的PV绑定成功，Pod调度过程结束，完成目标应用的迁移。

另外，在一些实施例中，还包括：通过上述第二调度插件，监控所述目标应用所关联的PVC处于非绑定状态的时长，当所述时长超过预设值时，触发对所述PVC的重新绑定操作，即重新执行上述步骤1。

其中，关于目标应用的数据迁移过程，进一步详细说明如下：

如图3所示，Workflow任务包括启动两个任务Pod：客户端Pod和服务端Pod。其中：

客户端Pod负责将源PV对应的本地磁盘路径(即路径1)挂载到目标应用对应的Pod上，并启动rsyncd(remote synchronize，远程数据同步)进程，用于从路径1获取数据并向服务端Pod传输数据。

服务端Pod负责将调度器(Kube-scheduler)分配的目标路径(即路径2)，挂载到目标应用对应的Pod上，并监听客户端Pod与服务端Pod之间的端口(即873端口)，等待接收数据并存储到路径2下。

在一些实施例中，客户端Pod定期上报数据传输进度信息给目的节点中的localpath-csi组件。当localpath-csi组件通过workflow监控到客户端Pod传输数据完毕后，将设置workflow任务为成功状态。通过客户端Pod传输进度信息，可以更好地监控数据传输的进度，确保数据迁移任务的顺利进行。

然而，在异常场景下，源节点中的本地磁盘可能会出现文件***损坏、磁盘损坏或只读等问题，这些问题都会导致客户端Pod与服务端Pod之间的数据传输中断。

针对上述异常情况，在一些实施例中，客户端Pod可以获取异常原因并重新启动，并且如果客户端Pod重启次数超过预设次数(例如6次)，workflow任务会被标记为失败并通知用户。用户可以查看workflow任务失败原因，并可以触发workflow任务重新执行，直到完成数据迁移。通过这样的机制，可以及时捕捉并处理本地磁盘异常情况，保证数据传输的可靠性。并且，用户可以通过任务状态和失败原因来进行workflow任务的管理和重新执行，确保数据迁移的成功完成。

综上所述，相对于现有技术而言，本申请实施例充分利用了Kubernetes调度器的调度能力，能够帮助有状态应用的Pod实现合理的二次资源分配(即重调度)，无需人工干预来指定调度目的路径。这样可以提高资源利用率，减少人工操作的复杂性，并且能够更好地适应动态变化的环境。通过与Kubernetes调度器的紧密集成，本申请实施例提供了更智能、更自动化的应用迁移解决方案，参见图4，本申请实施例提供的一种应用迁移方法，总体包括：

S401、确定需要将源节点的目标应用(例如有状态应用)迁移到目的节点；

需要说明的是，本申请实施例中以有状态应用为例进行说明，但本申请实施例提供的技术方案并不限于对有状态应用的迁移。

S402、将所述目标应用所关联的持久化卷声明PVC解绑，并且为所述PVC设置迁移标签(例如migrate标签)，用于指示应用编排管理***的控制器(例如kube-controller中的pv-controller)不对设置有所述迁移标签的PVC进行绑定；

S403、删除所述目标应用的源持久化卷PV与所述PVC的绑定关系；

S404、驱逐所述源节点上的所述目标应用的容器Pod，触发所述应用编排管理***的调度器(例如kube-scheduler)将所述Pod重新调度到目的节点上；

S405、通过容器存储接口CSI组件(例如localpath-csi)将所述目标应用的源PV数据迁移到所述目的节点上，并创建目的PV，以及删除所述PVC的迁移标签；

S406、通过所述控制器建立所述目的PV与所述PVC的绑定关系。

可见，本申请实施例实现了将源节点的有状态应用迁移到目的节点，并解决了因有状态应用升级或扩容，导致的应用Pending后出现的服务不可用的问题，能够借助kube-scheduler等组件的能力，确定Pod调度的目的节点，并通过CSI组件实现了有状态应用数据的迁移，提高了有状态应用的可用性和弹性。

在一些实施例中，通过容器存储接口CSI组件将所述目标应用的源PV数据迁移到所述目的节点上，包括：

当所述CSI组件监控到设置有所述迁移标签的PVC时，通过创建工作流(workflow)任务，将所述目标应用的源PV数据迁移到所述目的节点上；其中，所述创建工作流任务包括在所述源节点创建客户端Pod，以及在所述目的节点创建服务端Pod，所述客户端Pod用于从所述源节点的第一路径获取所述源PV数据并发送给所述服务端Pod，所述服务端Pod用于接收所述客户端Pod发送的所述源PV数据，并存储到所述目的节点的第二路径。

本申请实施例中，通过工作流(workflow)任务方式实现了有状态应用数据的迁移，进一步提高了有状态应用的可用性和弹性。

在一些实施例中，所述客户端Pod，通过启动远程数据同步(即rsyncd)进程，从所述源节点的第一路径获取所述源PV数据并发送给所述服务端Pod。

本申请实施例中，通过使用lsyncd，数据的传输可以及时地进行，减少传输延迟和数据丢失的风险。

在一些实施例中，所述方法还包括：

通过所述客户端Pod周期性地获取数据传输进度；

当基于所述数据传输进度，确定所述客户端Pod传输数据完毕时，设置所述工作流任务为成功状态。

本申请实施例中，通过客户端Pod传输进度信息，可以更好地监控数据传输的进度，确保数据迁移任务的顺利进行。

在一些实施例中，所述方法还包括：

当发生所述客户端Pod与所述服务端Pod之间的数据传输中断的异常情况时，通过所述客户端Pod获取异常原因，并重新启动所述客户端Pod从所述源节点的第一路径获取所述源PV数据并发送给所述服务端Pod，其中，当所述客户端Pod重启次数超过预设次数时，标记所述工作流任务为失败状态并通知用户。

可见，本申请实施例中，通过这样的机制，可以及时捕捉并处理本地磁盘异常情况，保证数据传输的可靠性。并且，用户可以通过任务状态和失败原因来进行workflow任务的管理和重新执行，确保数据迁移的成功完成。

在一些实施例中，所述确定需要将源节点的目标应用迁移到目的节点，包括：

通过设置在所述应用编排管理***的调度器(即kube-scheduler)中的预设第一调度插件，监控到满足如下条件之一或组合时，确定需要将源节点的目标应用迁移到目的节点：

所述源节点的CPU被所述目标应用之外的其他应用占用，并且，所述源节点没有可以驱逐的无状态应用(例如上述场景一)；

所述目标应用重新上线后，所述源节点上的原有应用与所述重新上线的目标应用具有反亲和性(例如上述场景二)；

所述目标应用重新上线后，所述目标应用所关联的PVC的卷信息发生变更(例如上述场景三)。

所述目标应用所关联的PVC的卷信息发生变更，例如包括所述目标应用的存储介质发生变化，和/或，所述目标应用的卷的大小发生变化。

从而，本申请实施例可以针对资源不足、反亲和性以及卷信息变更等场景，导致的应用在源节点不可用的情况，将该应用迁移到目的节点上，使其可以在目的节点上正常运行，避免应用无法为用户提供服务的问题。

在一些实施例中，所述方法还包括：

当所述源节点的CPU被所述目标应用之外的其他应用占用时，驱逐所述源节点上的无状态应用，直到所述源节点的CPU满足运行所述目标应用的条件。

在一些实施例中，所述方法还包括：

通过设置在所述应用编排管理***的调度器(即kube-scheduler)中的预设第二调度插件，监控所述目标应用所关联的PVC处于非绑定状态的时长，当所述时长超过预设值时，触发对所述PVC的重新绑定操作。

从而，本申请实施例可以使得有状态应用关联的PVC能够尽快重新绑定，以实现应用的顺利迁移并运行。

下面介绍一下本申请实施例提供的设备或***，其中与上述方法中所述的相同或相应的技术特征的解释或举例说明，后续不再赘述。

本申请实施例提供的一种电子设备，例如可以是任何一种服务端设备，参见图5，例如包括：

处理器600，用于读取存储器620中的程序，执行下列过程：

确定需要将源节点的目标应用迁移到目的节点；

将所述目标应用所关联的持久化卷声明PVC解绑，并且为所述PVC设置迁移标签，用于指示应用编排管理***的控制器不对设置有所述迁移标签的PVC进行绑定；

删除所述目标应用的源持久化卷PV与所述PVC的绑定关系；

驱逐所述源节点上的所述目标应用的容器Pod，触发所述应用编排管理***的调度器将所述Pod重新调度到目的节点上；

通过容器存储接口CSI组件将所述目标应用的源PV数据迁移到所述目的节点上，并创建目的PV，以及删除所述PVC的迁移标签；

通过所述控制器建立所述目的PV与所述PVC的绑定关系。

在一些实施例中，通过容器存储接口CSI组件将所述目标应用的源PV数据迁移到所述目的节点上，包括：

当所述CSI组件监控到设置有所述迁移标签的PVC时，通过创建工作流任务，将所述目标应用的源PV数据迁移到所述目的节点上；其中，所述创建工作流任务包括在所述源节点创建客户端Pod，以及在所述目的节点创建服务端Pod，所述客户端Pod用于从所述源节点的第一路径获取所述源PV数据并发送给所述服务端Pod，所述服务端Pod用于接收所述客户端Pod发送的所述源PV数据，并存储到所述目的节点的第二路径。

在一些实施例中，所述客户端Pod，通过启动远程数据同步进程，从所述源节点的第一路径获取所述源PV数据并发送给所述服务端Pod。

在一些实施例中，所述处理器600，还用于读取存储器620中的程序，执行下列过程：

通过所述客户端Pod周期性地获取数据传输进度；

当基于所述数据传输进度，确定所述客户端Pod传输数据完毕时，设置所述工作流任务为成功状态。

在一些实施例中，所述处理器600，还用于读取存储器620中的程序，执行下列过程：

当发生所述客户端Pod与所述服务端Pod之间的数据传输中断的异常情况时，通过所述客户端Pod获取异常原因，并重新启动所述客户端Pod从所述源节点的第一路径获取所述源PV数据并发送给所述服务端Pod，其中，当所述客户端Pod重启次数超过预设次数时，标记所述工作流任务为失败状态并通知用户。

在一些实施例中，所述确定需要将源节点的目标应用迁移到目的节点，包括：

通过设置在所述应用编排管理***的调度器中的预设第一调度插件，监控到满足如下条件之一或组合时，确定需要将源节点的目标应用迁移到目的节点：

所述源节点的CPU被所述目标应用之外的其他应用占用，并且，所述源节点没有可以驱逐的无状态应用；

所述目标应用重新上线后，所述源节点上的原有应用与所述重新上线的目标应用具有反亲和性；

所述目标应用重新上线后，所述目标应用所关联的PVC的卷信息发生变更。

在一些实施例中，所述处理器600，还用于读取存储器620中的程序，执行下列过程：

当所述源节点的CPU被所述目标应用之外的其他应用占用时，驱逐所述源节点上的无状态应用，直到所述源节点的CPU满足运行所述目标应用的条件。

在一些实施例中，所述处理器600，还用于读取存储器620中的程序，执行下列过程：

通过设置在所述应用编排管理***的调度器中的预设第二调度插件，监控所述目标应用所关联的PVC处于非绑定状态的时长，当所述时长超过预设值时，触发对所述PVC的重新绑定操作。

收发机610，用于在处理器600的控制下接收和发送数据。

其中，在图5中，总线架构可以包括任意数量的互联的总线和桥，具体由处理器600代表的一个或多个处理器和存储器620代表的存储器的各种电路链接在一起。总线架构还可以将诸如***设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。收发机610可以是多个元件，即包括发送机和接收机，提供用于在传输介质上与各种其他***通信的单元，这些传输介质包括，这些传输介质包括无线信道、有线信道、光缆等传输介质。针对不同的用户设备，用户接口630还可以是能够外接内接需要设备的接口，连接的设备包括但不限于小键盘、显示器、扬声器、麦克风、操纵杆等。

处理器600负责管理总线架构和通常的处理，存储器620可以存储处理器600在执行操作时所使用的数据。

在一些实施方式中，处理器600可以是CPU(中央处埋器)、ASIC(ApplicationSpecific Integrated Circuit，专用集成电路)、FPGA(Field－Programmable GateArray，现场可编程门阵列)或CPLD(Complex Programmable Logic Device，复杂可编程逻辑器件)，处理器也可以采用多核架构。

处理器通过调用存储器存储的计算机程序，用于按照获得的可执行指令执行本申请实施例提供的任一所述方法。处理器与存储器也可以物理上分开布置。

在此需要说明的是，本申请实施例提供的上述***，能够实现上述方法实施例所实现的所有方法步骤，且能够达到相同的技术效果，在此不再对本实施例中与方法实施例相同的部分及有益效果进行具体赘述。

相应地，参见图6，本申请实施例提供的一种应用迁移***，包括：调度器组件11(例如上述的kube-scheduler)、重调度组件12(例如上述的cube-descheduler)、CSI组件13(例如上述的localpath-csi)、控制器组件14(例如上述的kube-controller)；其中，

所述调度器组件11，用于确定需要将源节点的目标应用迁移到目的节点；以及，在所述重调度组件的触发下，将所述Pod重新调度到目的节点上；

所述重调度组件12，用于：

将所述目标应用所关联的持久化卷声明PVC解绑，并且为所述PVC设置迁移标签，用于指示所述控制器组件不对设置有所述迁移标签的PVC进行绑定；

删除所述目标应用的源持久化卷PV与所述PVC的绑定关系；

驱逐所述源节点上的所述目标应用的容器Pod，触发所述调度器组件将所述Pod重新调度到目的节点上；

所述CSI组件13，用于将所述目标应用的源PV数据迁移到所述目的节点上，并创建目的PV，以及删除所述PVC的迁移标签；

所述控制器组件14，用于建立所述目的PV与所述PVC的绑定关系。

需要说明的是，上述调度器组件11、重调度组件12、CSI组件13、控制器组件14等各个组件，可以理解为功能模块或者单元。

调度器组件11、重调度组件12、CSI组件13、控制器组件14相互之间可以直接具有通信连接关系，也可以是间接具有通信连接关系，例如，调度器组件11、重调度组件12、CSI组件13、控制器组件14，都通过监控另一组件，例如上述的kube-apiserver组件，执行上述相应操作，具体可以参见图2所示的举例说明，此处不再赘述。

需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例提供的任一所述的设备或***，具体可以为桌面计算机、便携式计算机、智能手机、平板电脑、个人数字助理(Personal Digital Assistant，PDA)等。可以包括中央处理器(Center Processing Unit，CPU)、存储器、输入/输出设备等，输入设备可以包括键盘、鼠标、触摸屏等，输出设备可以包括显示设备，如液晶显示器(Liquid CrystalDisplay，LCD)、阴极射线管(Cathode Ray Tube，CRT)等。

存储器可以包括只读存储器(ROM)和随机存取存储器(RAM)，并向处理器提供存储器中存储的程序指令和数据。在本申请实施例中，存储器可以用于存储本申请实施例提供的任一所述方法的程序。

处理器通过调用存储器存储的程序指令，处理器用于按照获得的程序指令执行本申请实施例提供的任一所述方法。

本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述实施例中的任一所述方法。所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、***或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请实施例提供了一种计算机可读存储介质，用于储存为上述本申请实施例提供的***所用的计算机程序指令，其包含用于执行上述本申请实施例提供的任一方法的程序。所述计算机可读存储介质，可以是非暂时性计算机可读介质。

所述计算机可读存储介质可以是计算机能够存取的任何可用介质或数据存储设备，包括但不限于磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NANDFLASH)、固态硬盘(SSD))等。

应当理解：

通信网络中的实体经由其往来传送流量的接入技术可以是任何合适的当前或未来技术，诸如可以使用WLAN(无线本地接入网络)、WiMAX(微波接入全球互操作性)、LTE、LTE-A、5G、蓝牙、红外等；另外，实施例还可以应用有线技术，例如，基于IP的接入技术，如有线网络或固定线路。

适合于被实现为软件代码或其一部分并使用处理器或处理功能运行的实施例是独立于软件代码的，并且可以使用任何已知或未来开发的编程语言来规定，诸如高级编程语言，诸如objective-C、C、C++、C#、Java、Python、Javascript、其他脚本语言等，或低级编程语言，诸如机器语言或汇编程序。

实施例的实现是独立于硬件的，并且可以使用任何已知或未来开发的硬件技术或其任何混合来实现，诸如微处理器或CPU(中央处理单元)、MOS(金属氧化物半导体)、CMOS(互补MOS)、BiMOS(双极MOS)、BiCMOS(双极CMOS)、ECL(发射极耦合逻辑)和/或TTL(晶体管-晶体管逻辑)。

实施例可以被实现为单独的设备、***、单元、部件或功能，或者以分布式方式实现，例如，可以在处理中使用或共享一个或多个处理器或处理功能，或者可以在处理中使用和共享一个或多个处理段或处理部分，其中，一个物理处理器或多于一个的物理处理器可以被用于实现一个或多个专用于如所描述的特定处理的处理部分。

***可以由半导体芯片、芯片组或包括这种芯片或芯片组的(硬件)模块来实现。

实施例还可以被实现为硬件和软件的任何组合，诸如ASIC(应用特定IC(集成电路))组件、FPGA(现场可编程门阵列)或CPLD(复杂可编程逻辑器件)组件或DSP(数字信号处理器)组件。

实施例还可以被实现为计算机程序产品，包括在其中体现计算机可读程序代码的计算机可用介质，该计算机可读程序代码适应于执行如实施例中所描述的过程，其中，该计算机可用介质可以是非暂时性介质。

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

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

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

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

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种应用迁移方法，其特征在于，所述方法包括：

确定需要将源节点的目标应用迁移到目的节点；

将所述目标应用所关联的持久化卷声明PVC解绑，并且为所述PVC设置迁移标签，用于指示应用编排管理***的控制器不对设置有所述迁移标签的PVC进行绑定；

删除所述目标应用的源持久化卷PV与所述PVC的绑定关系；

驱逐所述源节点上的所述目标应用的容器Pod，触发所述应用编排管理***的调度器将所述Pod重新调度到目的节点上；

通过容器存储接口CSI组件将所述目标应用的源PV数据迁移到所述目的节点上，并创建目的PV，以及删除所述PVC的迁移标签；

通过所述控制器建立所述目的PV与所述PVC的绑定关系。

2.根据权利要求1所述的方法，其特征在于，通过容器存储接口CSI组件将所述目标应用的源PV数据迁移到所述目的节点上，包括：

当所述CSI组件监控到设置有所述迁移标签的PVC时，通过创建工作流任务，将所述目标应用的源PV数据迁移到所述目的节点上；其中，所述创建工作流任务包括在所述源节点创建客户端Pod，以及在所述目的节点创建服务端Pod，所述客户端Pod用于从所述源节点的第一路径获取所述源PV数据并发送给所述服务端Pod，所述服务端Pod用于接收所述客户端Pod发送的所述源PV数据，并存储到所述目的节点的第二路径。

3.根据权利要求2所述的方法，其特征在于，所述客户端Pod，通过启动远程数据同步进程，从所述源节点的第一路径获取所述源PV数据并发送给所述服务端Pod。

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

通过所述客户端Pod周期性地获取数据传输进度；

当基于所述数据传输进度，确定所述客户端Pod传输数据完毕时，设置所述工作流任务为成功状态。

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

当发生所述客户端Pod与所述服务端Pod之间的数据传输中断的异常情况时，通过所述客户端Pod获取异常原因，并重新启动所述客户端Pod从所述源节点的第一路径获取所述源PV数据并发送给所述服务端Pod，其中，当所述客户端Pod重启次数超过预设次数时，标记所述工作流任务为失败状态并通知用户。

6.根据权利要求1所述的方法，其特征在于，所述确定需要将源节点的目标应用迁移到目的节点，包括：

通过设置在所述应用编排管理***的调度器中的预设第一调度插件，监控到满足如下条件之一或组合时，确定需要将源节点的目标应用迁移到目的节点：

所述源节点的CPU被所述目标应用之外的其他应用占用，并且，所述源节点没有可以驱逐的无状态应用；

所述目标应用重新上线后，所述源节点上的原有应用与所述重新上线的目标应用具有反亲和性；

所述目标应用重新上线后，所述目标应用所关联的PVC的卷信息发生变更。

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

通过设置在所述应用编排管理***的调度器中的预设第二调度插件，监控所述目标应用所关联的PVC处于非绑定状态的时长，当所述时长超过预设值时，触发对所述PVC的重新绑定操作。

8.一种应用迁移***，其特征在于，所述***包括：调度器组件、重调度组件、CSI组件、控制器组件；其中，

所述调度器组件，用于确定需要将源节点的目标应用迁移到目的节点；以及，在所述重调度组件的触发下，将所述Pod重新调度到目的节点上；

所述重调度组件，用于：

将所述目标应用所关联的持久化卷声明PVC解绑，并且为所述PVC设置迁移标签，用于指示所述控制器组件不对设置有所述迁移标签的PVC进行绑定；

删除所述目标应用的源持久化卷PV与所述PVC的绑定关系；

驱逐所述源节点上的所述目标应用的容器Pod，触发所述调度器组件将所述Pod重新调度到目的节点上；

所述CSI组件，用于将所述目标应用的源PV数据迁移到所述目的节点上，并创建目的PV，以及删除所述PVC的迁移标签；

所述控制器组件，用于建立所述目的PV与所述PVC的绑定关系。

9.一种电子设备，其特征在于，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行权利要求1至7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使所述计算机执行权利要求1至7任一项所述的方法。