kubevirt（三）迁移（migration）

nuczzz

已于 2023-02-06 21:35:53 修改

阅读量1.8k

点赞数 1

分类专栏： kubernetes 文章标签： kubernetes 云计算

于 2022-12-27 18:12:46 首次发布

本文链接：https://blog.csdn.net/NUCEMLS/article/details/128459693

版权

kubernetes 专栏收录该内容

16 篇文章 12 订阅

订阅专栏

通过之前《kubevirt（一）虚拟化技术》和《kubevirt（二）实现原理》两篇文章，我们对kubevirt有了初步的了解，本文基于这些内容，我们来看看kubevirt虚拟机的迁移（migration）。

注：

本文内容仅限于同一个kubernetes集群内的虚拟机迁移，且本文内容基于kubevirt@0.49.0

前言

虚拟机迁移一般是指因宿主机出现故障时，需要将上面运行的虚拟机迁移到其它宿主机上的过程。

在做虚拟机迁移前，首先需要考虑迁移前后宿主机的硬件资源差异性，包括宿主机架构（x86、ARM等）、宿主机cpu类型（Intel、AMD等）等因素，这部分内容需要结合具体业务场景具体分析，不在本文讨论范围内。

除去硬件资源差异，kubevirt虚拟机迁移还需要考虑以下问题：

kubevirt如何做kvm迁移？

kubevirt的kvm虚拟机是运行在pod中的，为了实现kvm迁移，kubevirt定义了一个叫作VirtualMachineInstanceMigration的CRD。用户如果想迁移kubevirt kvm，编写一个VirtualMachineInstanceMigration对象apply即可，apply后对应的controller会在其它节点创建一个新的kvm pod，之后再做切换，从而完成kvm的迁移。

迁移过程对业务的影响?

迁移可以分为冷迁移（offline migration，也叫常规迁移、离线迁移）和热迁移（live migration，也叫动态迁移、实时迁移），冷迁移在迁移之前需要将虚拟机关机，然后将虚拟机镜像和状态拷贝到目标宿主机，之后再启动；热迁移则是将虚拟机保存（save）/回复（restore），即将整个虚拟机的运行状态完整的保存下来，拷贝到其它宿主机上后快速的恢复。热迁移相比于冷迁移，对业务来说几乎无感知。

kubevirt的VirtualMachineInstanceMigration支持live migration，官方资料可参考《Live Migration in KubeVirt》

数据对迁移的限制？

这里说的数据主要考虑内存数据、系统盘/数据盘数据，系统盘和数据盘如果使用了宿主机的本地盘（如SSD），迁移后数据会丢失，云盘（包括pvc）则无影响。

如何保证kubevirt kvm pod不再调度到本机？

kubevirt的kvm pod调度由k8s调度器完成，因此为了防止新的kvm pod再次调度到本节点，可以通过给节点打污点等方法来解决。

业务方对虚拟机的ip是敏感的，如何保证迁移后虚拟机的ip不变？

kubevirt的kvm虚拟机是在pod中启动的，从而该pod和对应的虚拟机ip与k8s网络方案有关，因此可以考虑在CNI网络方案中实现kvm的固定ip。

VirtualMachineInstanceMigration

VirtualMachineInstanceMigration（下文简写vmiMigration）是kubevirt定义的一个CRD，接下来我们从源码和流程两个角度来看看kubevirt是如何通过这个CRD实现kvm迁移的。

vmiMigration源码分析

vmiMigration这个CRD的定义如下，从CRD的定义中可以看出，一个vmiMigration对应一台虚拟机（vmiMigration.spec.vmiName）的迁移，迁移本身是一个很复杂的过程，vmiMigration和vmi本身都有相关字段记录迁移的状态。

// staging/src/kubevirt.io/api/core/v1/types.go
type VirtualMachineInstanceMigration struct {
    metav1.TypeMeta   `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty"`
    Spec              VirtualMachineInstanceMigrationSpec   `json:"spec" valid:"required"`
    Status            VirtualMachineInstanceMigrationStatus `json:"status,omitempty"`
}

type VirtualMachineInstanceMigrationSpec struct {
    // The name of the VMI to perform the migration on. VMI must exist in the migration objects namespace
    VMIName string `json:"vmiName,omitempty" valid:"required"`
}

type VirtualMachineInstanceMigrationStatus struct {
    Phase      VirtualMachineInstanceMigrationPhase       `json:"phase,omitempty"`
    Conditions []VirtualMachineInstanceMigrationCondition `json:"conditions,omitempty"`
}

vmiMigration作为一个CRD必然会有对应的controller逻辑，它的controller逻辑是放在virt-controller中的，因此我们从virt-controller的入口开始：

// cmd/virt-controller/virt-controller.go
func main() {
    watch.Execute()
}

再到virt-controller的主逻辑找到vmiMigration controller的入口：

// pkg/virt-controller/watch/application.go
func Execute() {
    ...
    app.initCommon()
    ...
}

func (vca *VirtControllerApp) initCommon() {
    ...
    vca.migrationController = NewMigrationController(
        vca.templateService,
        vca.vmiInformer,
        vca.kvPodInformer,
        vca.migrationInformer,
        vca.nodeInformer,
        vca.persistentVolumeClaimInformer,
        vca.pdbInformer,
        vca.migrationPolicyInformer,
        vca.vmiRecorder,
        vca.clientSet,
        vca.clusterConfig,
    )
    ...

vmiMigration controller注册事件处理函数如下，它会监听vmi的add/delete/update事件、pod的add/delete/update事件、vmiMigration的add/delete/update事件以及pdb（PodDisruptionBudget）的update事件。

// pkg/virt-controller/watch/migration.go
func NewMigrationController(...) {
    ...
    c.vmiInformer.AddEventHandler(cache.ResourceEventHandlerFuncs{
        AddFunc:    c.addVMI,
        DeleteFunc: c.deleteVMI,
        UpdateFunc: c.updateVMI,
    })

    c.podInformer.AddEventHandler(cache.ResourceEventHandlerFuncs{
        AddFunc:    c.addPod,
        DeleteFunc: c.deletePod,
        UpdateFunc: c.updatePod,
    })

    c.migrationInformer.AddEventHandler(cache.ResourceEventHandlerFuncs{
        AddFunc:    c.addMigration,
        DeleteFunc: c.deleteMigration,
        UpdateFunc: c.updateMigration,
    })

    c.pdbInformer.AddEventHandler(cache.ResourceEventHandlerFuncs{
        UpdateFunc: c.updatePDB,
    })
    ...
}

不管上述哪种事件处理函数，都是去找到关联的vmiMigration对象然后放入队列中。我们以pod的update事件处理函数为例来看：

// pkg/virt-controller/watch/migration.go
// When a pod is updated, figure out what migration manages it and wake them
// up. If the labels of the pod have changed we need to awaken both the old
// and new migration. old and cur must be *v1.Pod types.
func (c *MigrationController) updatePod(old, cur interface{}) {
    curPod := cur.(*k8sv1.Pod)
    oldPod := old.(*k8sv1.Pod)
    if curPod.ResourceVersion == oldPod.ResourceVersion {
        // Periodic resync will send update events for all known pods.
        // Two different versions of the same pod will always have different RVs.
        return
    }

    labelChanged := !reflect.DeepEqual(curPod.Labels, oldPod.Labels)
    if curPod.DeletionTimestamp != nil {
        // having a pod marked for deletion is enough to count as a deletion expectation
        c.deletePod(curPod)
        if labelChanged {
            // we don't need to check the oldPod.DeletionTimestamp because DeletionTimestamp cannot be unset.
            c.deletePod(oldPod)
        }
        return
    }

    curControllerRef := c.getControllerOf(curPod)
    oldControllerRef := c.getControllerOf(oldPod)
    controllerRefChanged := !reflect.DeepEqual(curControllerRef, oldControllerRef)
    if controllerRefChanged && oldControllerRef != nil {
        // The ControllerRef was changed. Sync the old controller, if any.
        if migration := c.resolveControllerRef(oldPod.Namespace, oldControllerRef); migration != nil {
            c.enqueueMigration(migration)
        }
    }

    migration := c.resolveControllerRef(curPod.Namespace, curControllerRef)
    if migration == nil {
        return
    }
    log.Log.V(4).Object(curPod).Infof("Pod updated")
    c.enqueueMigration(migration) // 这里把关联的vmiMigration对象放入队列中
    return
}

有了上面入队的逻辑，再来看看队列消费逻辑：

// pkg/virt-controller/watch/migration.go
func (c *MigrationController) runWorker() {
    // 不断消费队列数据
    for c.Execute() {
    }
}

func (c *MigrationController) Execute() bool {
    // 如果队列中有数据，每次从队列中取一个数据消费
    key, quit := c.Queue.Get()
    if quit {
        return false
    }
    defer c.Queue.Done(key)
    err := c.execute(key.(string))

    if err != nil {
        log.Log.Reason(err).Infof("reenqueuing Migration %v", key)
        c.Queue.AddRateLimited(key)
    } else {
        log.Log.V(4).Infof("processed Migration %v", key)
        c.Queue.Forget(key)
    }
    return true
}

func (c *MigrationController) execute(key string) error{
    ...
    if needSync {
        syncErr = c.sync(key, migration, vmi, targetPods)
    }
    err = c.updateStatus(migration, vmi, targetPods)
    ...
}

队列消费这边有两个重要的函数：c.sync和c.updateStatus。先看看c.sync：

// pkg/virt-controller/watch/migration.go
func (c *MigrationController) sync(...) {
    ...
    // 根据vmiMigration的状态做不同处理
    switch migration.Status.Phase {
    case virtv1.MigrationPending:
        if !targetPodExists {
            // 如果目标pod（迁移后起来的pod）还不存在，则会根据vmi和vmi的pod生成一个新的pod
            // 这个pod就是迁移后跑虚拟机的pod
        } else if isPodRead(pod) {
            // 如果目标pod已存在且是ready状态，检查是否热插拔（hotplug）卷
            // 如果有，则会检查attachmentPods有没有，没有就创建
        } else {
            // 处理超时的目标pod，超时没起来超过一定时间自动删除（后续逻辑会继续尝试重建）
        }
    
    case virtv1.MigrationScheduling:
        // 处理超时的目标pod，超时没起来超过一定时间自动删除
        
    case virtv1.MigrationScheduled:
        // 当目标pod存在且ready时，更新vmi的status.migrationState相关字段，并将vmi和目标pod关联起来
        
    case virtv1.MigrationPreparingTarget, virtv1.MigrationTargetReady, virtv1.MigrationFailed:
        // 如果目标pod不存在或者已经退出，更新vmi的status.migrationState相关字段，并标注该vmi的迁移结束
    
    case virtv1.MigrationRunning:
        // 如果vmiMigration的deletionTimestamp被打上（即vmiMigration被删除）
        // 更新vmi的status.migrationState相关字段，并标注为abort
    }
    ...

再看看c.updateStatus：

// pkg/virt-controller/watch/migration.go
func (c *MigrationController) updateStatus(...) {
    ...
    if migration.IsFinal() {
        // 如果迁移已经结束（不管是成功还是失败），移除vmiMigration的finalizer
    } else if vmi == nil {
        // 如果vmi不存在，vmiMigration.status.phase标识为failed
    } else if vmi.IsFinal() {
        // 如果vmi已经是结束状态（failed或succeed），vmiMigration.status.phase标识为failed
    } else if podExists && podIsDown(pod) {
        // 如果目标pod存在但是是failed或succeed状态，vmiMigration.status.phase标识为failed
    } else if migration.TargetIsCreated() && !podExists {
        // 如果vmiMigration状态中标识目标pod已创建但实际目标pod不存在，，vmiMigration.status.phase标识为failed
    } else if migration.TargetIsHandedOff() && vmi.Status.MigrationState == nil {
        // 如果vmiMigration状态是已结束，但vmi.status.migrationState还是空的，vmiMigration.status.phase标识为failed
    } else if migration.TargetIsHandedOff() &&
        vmi.Status.MigrationState != nil &&
        vmi.Status.MigrationState.MigrationUID != migration.UID {
        // 如果vmiMigration状态是已结束，但vmi的migration UID不是自己，vmiMigration.status.phase标识为failed
    }else if vmi.Status.MigrationState != nil &&
        vmi.Status.MigrationState.MigrationUID == migration.UID &&
        vmi.Status.MigrationState.Failed {
        // 如果vmi的migration UID是自己但是vmi migration标识为failed，vmiMigration.status.phase也标识为failed
    } else if migration.DeletionTimestamp != nil && !migration.IsFinal() &&
        !conditionManager.HasCondition(migration, virtv1.VirtualMachineInstanceMigrationAbortRequested) {
        // 如果vmiMigration被打上删除标记，但本身状态不是终止状态，vmiMigration的condition会增加一个abort记录
    } else if attachmentPodExists && podIsDown(attachmentPod) {
        // 热插拔pod不正常时，vmiMigration.status.phase也标识为failed
    } else {
        switch migration.Status.Phase {
        case virtv1.MigrationPhaseUnset:
            // 如果vmiMigration状态没有设置（为空），且vmi可以迁移，则更新vmiMigration状态为Pending
        case virtv1.MigrationPending:
            // 如果状态为Pending，且目标pod已存在，则更新vmiMigration状态为Scheduling
        case virtv1.MigrationScheduling:
            // 如果状态为Scheduling，且目标pod已经ready，则更新vmiMigration状态为Scheduled
        case virtv1.MigrationScheduled:
            // 如果状态为Scheduled，且vmi.status.migrationState.targetNode不为空，则更新vmiMigration状态为PreparingTarget
        case virtv1.MigrationPreparingTarget:
            // 如果状态为PreparingTarget，且vmi.status.migrationState.targetNodeAddress不为空，则更新vmiMigration状态为TargetReady
        case virtv1.MigrationTargetReady:
            // 如果状态为TargetReady，且vmi.status.migrationState.StartTimestamp不为空（即已经开始迁移），则更新vmiMigration状态为Running
        case virtv1.MigrationRunning:
            // 如果状态是Running，且vmi.status.migrationState.completed = true，则更新vmiMigration状态为Succeed
        }
    }
    ...
}

通过代码可以发现，单纯依靠vmiMigration controller是无法完成整个迁移过程的，因为vmi.status.migrationState下的targetNode、startTimestamp、completed等字段都不是在vmiMigration controller中设置。事实上这部分数据是virt-handler设置的，virt-handler这部分逻辑从代码上不是很好讲述，因此本文略过此部分，但在下文的流程中会对virt-handler的作用做相关说明。

流程分析

有了上面的源码分析，我们假设现在有一个running的kvm（即存在一个running状态的vmi和pod），此时apply一个VirtualMachineInstanceMigration会发生什么：

在这里插入图片描述

初始状态，k8s中存在一个vmi和它对应的pod（src pod），即etcd中存在一个vmi对象和一个src pod对象，且node以上正常运行着这个pod；
kubectl apply一个vmiMigration；
apiServer收到这个请求，把vmiMigration对象存入etcd；
virt-controller中的vmiMigration controller（后文简称migration controler）的informer机制监听到有vmiMigration创建，且状态未设置（为空），于是调apiServer接口把vmiMigration状态更新为Pending；
apiServer更新etcd中vmiMigration对象状态为Pending；
migration controller的informer机制监听到vmiMigration的update事件，且状态是Pending，且目标pod（dst pod）还不存在，则调apiServer接口创建dst pod；
apiServer把dst pod对象存入etcd；
migration controller监听到dst pod创建事件，调apiServer接口更新vmiMigration状态为Scheduling；
apiServer更新etcd中的vmiMigration状态为Scheduling；
k8s scheduler的informer监听到dst pod创建，通过调度算法，把dst pod的spec.nodeName设置为node2，并调apiServer接口更新pod信息；
apiServer更新src pod的spec.nodeName字段；
node2上的kubelet创建dst pod，并不断向apiServer更新pod状态，包括最终dst pod变成ready状态；
apiServer接收node2上kubelet上报的dst pod状态，更新到etcd中；
经过一段时间后，dst pod变为ready状态，并被migration controller监听到，于是migration controller调apiServer更新vmiMigration状态为Scheduled；
apiServer更新etcd中的vmiMigration状态为Scheduled；
migration controller监听到vmiMigration状态变为Scheduled，查找集群中的migration policy（kubevirt的另一个CRD资源），并调apiServer更新vmi（注意这里是vmi而不是vmiMigration）status.migrationState下的migrationUID（更新为vmiMigration的uid）、targetNode（即node2）、sourceNode（即node1）、targetPodName（dst pod名称）、migrationPolicyName和migrationConfiguration字段；
apiServer更新etcd中vmi对象的status.migrationState下上述字段；
migration controller监听到vmiMigration状态是Scheduled且vmi对象的status.migrationState.targetNode不为空，调apiServer更新vmiMigration状态为PreparingTarget；
apiServer更新etcd中vmiMigration状态为PreparingTarget；
node2上的virt-handler会先通过grpc调用virt-launcher方法拿到一些数据，然后基于这些数据启动一个dst migration proxy，用于后续迁移时数据传输；同理node1上的virt-handler也会起个src migration proxy，这两个proxy之间的通信可以配置另外的网卡，防止迁移流量影响k8s本身网络；之后node2上virt-handler的vmController调apiServer接口给vmi打上migration的finalizer，同时更新vmi.status.migrationState下的targetNodeAddress和targetDirectMigrationNodePorts。virt-handler是以daemonSet+hostNetwork形式部署的，所以targetNodeAddress其实只需要virt-handler取其pod ip即可。
apiServer更新etcd中vmi的migration finalizer和targetNodeAddress、targetDirectMigrationNodePorts字段；
migration controller监听到vmi的targetNodeAddress不为空，调apiServer接口更新vmiMigration状态为TargetReady；
apiServer更新etcd中的vmiMigration状态为TargetReady；
node1上virt-handler的vmController会在第19步后，通过unix sock的方式调用源pod virt-launcher的grpc接口，virt-launchert调用libvirt开始异步执行migration，如果是nonroot，uri为qemu+unix:///session?socket={源proxy unix socket文件}；否则uri为qemu+unix:///system?socket={源proxy unix socket文件}。最后如果node1上virt-handler发现migration已经开始了，则调apiServer接口更新vmi的status.migrationState.startTimestamp等字段；
apiServer更新etcd中vmi的status.migrationState.startTimestamp等字段；
migrationController监听到vmi的status.migrationState.startTimestamp不为空，调apiServer接口更新vmiMigration状态为Running；
apiServer更新etcd中vmiMigration的状态为Running；
node1上virt-handler的vmController会调virt-launcher接口检查migration是否已完成，如果已完成调apiServer接口更新vmi的status.migrationState.completed为true；
apiServer更新etcd中vmi的status.migrationState.completed为true；
migration监听到vmi.status.migrationState.completed为true，调apiServer更新vmiMigration状态为succeeded；
apiServer更新etcd中vmiMigration状态为succeeded；
node1和node2上virt-handler的vmController执行相关清理动作，包括清理proxy、删除源kvm对应的domain资源等。