为什么你的KubeVirt虚拟机无法在集群间迁移——以及EVPN如何解决这一问题
内容提要
本文介绍如何利用OpenPERouter和EVPN/VXLAN，在Kubernetes集群间实现KubeVirt虚拟机跨集群实时迁移。通过创建L2VNI自定义资源，搭建跨站点的二层网络和专用迁移网络，解决IP/MAC保持和流量隔离问题。平台团队可通过声明式配置管理网络，无需依赖物理网络变更，实现虚拟机无缝迁移。
延伸解读
网络是跨集群迁移的真正瓶颈
KubeVirt 的实时迁移技术本身已支持跨集群，但实际落地时，网络往往成为最大障碍。虚拟机迁移到目标集群后，必须保持原有的 IP 和 MAC 地址，这要求两个站点之间具备二层网络连通性。传统做法需要新增 VLAN、调整交换机配置，甚至采购新硬件，涉及变更窗口和工单流程，耗时数周。而 Kubernetes 默认网络无法满足这一需求，因此需要额外的网络方案来支撑。
EVPN/VXLAN 以声明式方式替代传统网络配置
OpenPERouter 通过 CRD 将 EVPN/VXLAN 配置引入 Kubernetes，使得创建跨集群的二层网络和专用迁移网络变得像部署应用一样简单。只需定义 L2VNI 资源，指定 VNI 和 VRF，即可建立覆盖网络，无需改动物理网络。这改变了运维模式：平台团队不再需要向网络团队提交变更请求，而是直接通过 Kubernetes API 声明网络需求，实现快速、可版本控制的网络配置。
迁移网络隔离与 IPAM 策略需提前规划
文章强调，迁移流量应使用独立的 VNI 和 VRF，与业务流量隔离，以避免拥塞和延迟。同时，跨集群的 IP 地址管理需要避免冲突，示例中使用 Whereabouts 并配置互补的排除范围，但也可选择其他支持分区分配的 IPAM 方案。这些细节需要在部署前仔细设计，否则可能影响迁移的稳定性和可维护性。
Q&A
为什么KubeVirt虚拟机无法直接在集群间迁移？
因为跨集群实时迁移需要两个标准Kubernetes网络不提供的条件：一是跨站点的二层网络（stretched L2 domain），以保证虚拟机在目标集群保留相同的MAC和IP地址；二是专用的迁移网络，避免迁移流量与应用流量争抢带宽，造成拥塞和延迟。传统网络需要新增VLAN、配置交换机，甚至购买新硬件，流程繁琐耗时。
EVPN/VXLAN如何解决KubeVirt跨集群迁移的网络问题？
EVPN/VXLAN通过创建覆盖网络（overlay）来提供跨站点的二层连接和专用迁移网络。OpenPERouter将EVPN配置封装为Kubernetes自定义资源（CRD），通过L2VNI CR创建VXLAN二层覆盖网络，实现跨集群的MAC/IP保持；通过独立的VNI和VRF隔离迁移流量，无需修改物理网络。
OpenPERouter提供了哪些自定义资源来管理EVPN配置？
OpenPERouter通过三个自定义资源（CRD）管理EVPN配置：Underlay CR用于建立每个Kubernetes集群与TOR交换机之间的BGP对等；L2VNI CR创建二层覆盖网络（VXLAN段），由VNI标识并限定在VRF内；L3VNI CR实现不同子网间的IP路由，并连接集群与外部网络。
如何配置一个跨集群的二层网络用于KubeVirt虚拟机迁移？
需要在两个集群中创建相同的L2VNI自定义资源，指定相同的VNI和VRF，并配置linux-bridge类型和网关IP。例如，应用网络使用VNI 110和VRF red，迁移网络使用VNI 666和VRF rouge。这样两个集群的虚拟机就共享同一个二层广播域，实现IP和MAC的保持。
在KubeVirt跨集群迁移中，如何避免IP地址冲突？
可以使用Whereabouts IPAM插件，并通过互补的排除范围来划分每个集群的地址池。例如，两个集群的Network Attachment Definition覆盖相同的子网，但各自排除对方集群使用的地址范围，从而避免冲突。Whereabouts只是设计选择，任何支持跨集群分区地址池的IPAM方案都可以。
KubeVirt跨集群迁移的具体操作步骤是什么？
首先，在目标集群（集群B）上创建目标虚拟机，设置runStrategy: WaitAsReceiver，并配置与源虚拟机相同的MAC和IP。然后，在集群B上创建VirtualMachineInstanceMigration资源，声明接收迁移（receive），并指定migrationID和vmiName。最后，在集群A上创建匹配的VirtualMachineInstanceMigration资源，使用发送（sendTo）模式，并指向接收方的迁移IP（从接收方的.status.synchronizationAddresses获取），发起迁移。
使用OpenPERouter后，网络运维模式发生了哪些变化？
网络运维模式从“请求物理网络变更并等待”转变为“应用CR并等待覆盖网络收敛”。平台团队可以通过Kubernetes CRD声明式地管理二层扩展、专用迁移网络和VRF隔离，无需向网络团队提交工单或等待变更窗口。网络团队仍负责底层物理网络（underlay），但上层网络配置完全由Kubernetes管理。
