随着云原生技术从应用侧向数据中心和基础设施下沉，越来越多的企业开始使用 Kubernetes 和 KubeVirt 来运行虚拟化工作负载，实现在统一的控制平面同时管理虚拟机和容器。然而一方面虚拟机的使用场景和习惯都和容器有着显著的差异，另一方面新兴的容器网络并没有专门对虚拟化场景进行设计，功能的完备性和性能都与传统虚拟化网络存在较大差距。网络问题成为了云原生虚拟化的瓶颈所在。

Kube-OVN 由于使用了在传统虚拟化网络中得到广泛使用的 OVN/OVS，在开源后得到了很多 KubeVirt 用户的关注，一部分前沿的 KubeVirt 用户根据自己的使用场景进一步完善了 Kube-OVN 的网络能力。本文系统总结了 Kube-OVN 社区中针对 KubeVirt 优化的功能，可以帮助用户很好地解决云原生虚拟化面临的难题。

VM 固定地址

容器网络通常对地址是否固定不做要求，然而在 VM 的使用场景中，VM 的地址通常作为主要的访问方式，使用者通常要求 VM 的地址保持稳定，不能随着 VM 的启停，升级，迁移而发生变化。虚拟化的管理员通常也对地址的分配有着管控的需求，希望拥有指定 VM 地址的能力。

Kube-OVN 经过长时间的迭代目前支持了：

· VM 创建时指定 IP，VM 生命周期内地址保持固定

· VM 创建时随机地址分配，VM 生命周期内地址保持固定

· VM 热迁移过程中业务网卡保持地址固定

VM 创建时指定 IP

对于由管理员主动给 VM 分配地址，并在启动前确定地址的情况，只需要在 KubeVirt 的VirtualMachine 的template中的annotations增加 ovn.kubernetes.io/ip_address 来指定需要分配的地址。

以该方式启动的 VM，Kube-OVN 会自动按照 annotation 字段分配固定 IP，VM instance 重建启停不会导致 IP 变化。

【参考资料】

kube-ovn/static-ip.md at master · kubeovn/kube-ovn

VM 创建时地址随机分配，生命周期内固定

在一些场景下，管理员并不想每次都手动给 VM 指定地址，但是希望 VM 在创建后销毁前的地址能够保持不变，不会因为 VM 重启，升级，启停等操作发生变化。

Kube-OVN 在 v1.8.3 和 v1.9.1 后引入了将 VM 分配的地址和 VirtualMachine

实例关联的能力，Kube-OVN 内针对 VM 分配的地址生命周期将和 VirtualMachine 

实例生命周期一致，实现一对一的映射。管理员无需手动分配 VM 地址即可实现生命周期内 VM 地址的固定。

新版本 Kube-OVN 用户只需在 kube-ovn-controller 中增加如下参数即可开启这个功能：

--keep-vm-ip=true

【参考资料】

https://github.com/kubeovn/kube-ovn/issues/1297

https://github.com/kubeovn/kube-ovn/pull/1307

VM 热迁移的固定地址

KubeVirt 的热迁移在网络方面面临很大的挑战，尤其是在固定 IP 的场景下，如何保证 IP 不冲突就变得更为复杂。由于 KubeVirt 在热迁移中使用 default network 进行状态的同步，通过结合 multus-cni 将业务网络和迁移网络分离，我们可以在功能层面实现热迁移过程中的地址固定。

1、由于默认网络只用于热迁移，需要使用 multus-cni 将 Kube-OVN 作为附属网卡附加给 VM

2、给 VM 增加对应的 annotation 以开启固定 IP 和热迁移支持功能 

<attach>.<ns>.ovn.kubernetes.io/allow_live_migration: 'true’

3、由于 KubeVirt 的 DHCP 会设置错误的默认路由，需要增加 annotation

<attach >.<ns>[ovn.kubernetes.io/default_route:](<http://ovn.kubernetes.io/default_route:>) 'true'

来选择正确的默认路由网卡。

通过以上的配置 Kube-OVN 将会接管热迁移过程中网络的转移过程，选择合适的时间点进行网络切换。

【参考资料】

https://github.com/kubeovn/kube-ovn/pull/1001

多租户网络 

在传统的虚拟化使用场景中，依托于 VPC 网络的多租户一般被认为是最佳实践也是许多企业基础 IT 的已有运行方式。然而在容器领域，由于 Kubernetes 最早面向应用平台，缺乏对多租户级别隔离的支持，导致容器网络和 KubeVirt 上的多租户支持也变得困难。

Kube-OVN 通过引入了一组新的多租户网络 CRD，包括 VPC，Subnet,NAT-Gateway 在 Kubernetes 上实现了多租户网络的功能。KubeVirt 上的虚拟化管理可以通过控制网络所属的 VPC 和 Subnet 来实现不同的 VM 落在不同的租户网络，从而实现整个虚拟化方案的多租户。

此外 Kube-OVN 还提供了租户内的 LB/EIP/NAT/Route Table 等功能，使用户能够像控制传统虚拟化网络一样来控制云原生虚拟化下的网络。

【参考资料】

kube-ovn/vpc.md at master · kubeovn/kube-ovn

SR-IOV 以及 OVS-DPDK 支持 

KubeVirt 默认的 Pod 模式网络由于需要适配 CNI 的规范，存在着网络路径较长，性能较差的问题。而 SR-IOV 模式存在着功能不灵活，配置困难的问题。Kube-OVN 通过利用目前智能网卡所支持的 OVS offload 能力，将 SRIOV 设备直通给 KubeVirt 的 VM 实现了高性能，同时保留了地址分配和 OVN 逻辑流表的功能，实现了完整的 SDN 网络能力，达到了性能和功能的良好结合。

此外，尽管上游 KubeVirt 还没有对 OVS-DPDK 类型网络的支持，但是在 Kube-OVN 社区内很多用户独立开发了 KubeVirt 对 OVS-DPDK 的支持，同时也开发了 Kube-OVN 内对 OVS-DPDK 的支持，这样即使是普通网卡也可以通过 OVS-DPDK 用户态的加速能力来增强 VM 内的网络吞吐能力。

【参考资料】

kube-ovn/hw-offload-mellanox.md at master · kubeovn/kube-ovn

kube-ovn/hw-offload-corigine.md at master · kubeovn/kube-ovn

kube-ovn/dpdk-hybrid.md at master · kubeovn/kube-ovn

总结  

由于在技术选型上天生的亲近性，KubeVirt 社区的用户在 Kube-OVN 中贡献了大量针对云原生虚拟化进行强化的功能，包括固定地址，多租户网络和 SR-IOV 以及 OVS-DPDK 等功能。这些功能极大地强化了 KubeVirt 的云原生虚拟化体验，我们希望通过这篇文章总结 KubeVirt 所需要的一些特殊网络场景希望更多 KubeVirt 社区的用户可以来体验这些功能，并将更多的功能需求反馈给 Kube-OVN 社区。

有奖调研！云原生虚拟化需求调查 

为了了解更多云原生虚拟化场景的需求，优化使用体验，Kube-OVN社区诚邀您参加《云原生虚拟化需求调查》

参与问卷填写，我们将抽取30位用户，赠送社区精美纪念品!

-------  问卷共5题， 仅需2分钟-------

【扫码】或点击【此处】填写

相关阅读：

上一篇：Kube-OVN：大型银行技术团队推荐的金融级云原生网络方案

下一篇：Kube-OVN1.9.0新版本发布｜VPC的网络能力增强，支持优先级QoS;支持集成 Cilium 策略等