KubeVirt虚拟机存储及网络卸载加速解决方案

1.  方案背景

1.1. KubeVirt介绍

随着云计算和容器技术的飞速发展，Kubernetes已成为业界公认的容器编排标准，为用户提供了强大、灵活且可扩展的平台来部署和管理各类应用。然而，在企业的实际应用中，仍有许多传统应用或遗留系统难以直接容器化，通常采用传统的虚拟化技术来支撑。因此，企业需要同时运行容器和虚拟机的混合云或私有云环境，以便开发者和运维人员方便地管理和维护这两种类型的工作负载，这促使了KubeVirt项目的诞生。

KubeVirt是一个开源项目，由Red Hat、IBM、Google、Intel和SUSE等多家公司共同推动和贡献。该项目旨在通过Kubernetes来管理和运行虚拟机（VMs），使虚拟机能够像容器一样被部署和消费。KubeVirt扩展了Kubernetes的API，增加了VirtualMachine和VirtualMachineInstance等自定义资源定义（CRDs），允许用户通过YAML文件或kubectl命令来管理虚拟机，极大简化了虚拟机的创建、更新、删除和查询过程。

KubeVirt 的价值主要体现在统一的资源管理，使得 Kubernetes 能够同时管理容器和虚拟机，为用户提供统一的资源管理界面。这消除了容器和虚拟机之间的管理界限，提高了资源管理的灵活性和效率，为用户提供了更多的选择，确保了应用的完整性和性能，促进了传统应用的现代化和云原生转型。

1.2. 问题与挑战

KubeVirt在提供虚拟机实例的部署和管理能力时，会面临着诸多网络和存储方面的问题与挑战。

如上图所示，构建KubeVirt虚拟机环境需要先启动一个Pod，在Pod中构建虚拟机的运行环境。

在无DPU/SmartNIC的场景下，Pod通过Kubernetes CNI创建的veth pair连接网络， 虚拟机为了对接CNI接入Pod中的网卡（eth0-nic），传统的虚拟机环境是需要创建网桥设备（k6t-eth0），网卡（eth0-nic）连接到网桥设备，然后再创建TAP设备（tap0），TAP设备（tap0）的一端连接到网桥设备，另外一端连接虚拟机，这样虚拟机网络打通了与主机上OVS的网络连接。在上图中可以看到，虚拟机的网络路径为：ovs --> vethxxx --> eth0-nic --> k6t-eth0 --> tap0 --> eth0。

此外，Pod的存储是通过Kubernetes CSI挂载到主机上云盘设备，传统网络存储都是基于TCP的iscsi/rbd/nvmeof-tcp提供的远端存储，在KubeVirt虚拟机环境中，远端存储被CSI挂载到Pod中直接被虚拟机使用。

如上所述，在KubeVirt虚拟机环境中，网络和存储的配置面临着一系列问题与挑战：

1、网络路径复杂且冗长：

在无DPU/SmartNIC的场景下，虚拟机网络路径包含了多个虚拟设备（如veth pair、网桥、TAP设备等），这使得网络路径复杂且冗长，这种长路径不仅增加了数据包处理的复杂度，提升了运维排障难度，还可能导致更高的延迟和性能瓶颈。

2、资源消耗高：

路径中过多的网络虚拟设备需要CPU和内存资源来处理数据包的转发和路由。这些资源消耗在高负载场景下尤为显著，可能导致宿主机资源紧张，整体资源利用率低。

3、网络性能低下：

由于网络路径复杂和资源消耗高，虚拟机的网络性能往往受到限制，在高吞吐量或低延迟要求的应用场景中，这种性能问题尤为明显。

4、基于TCP的远端存储存在性能瓶颈：

使用iSCSI、RBD（Ceph RBD）或NVMe-oF（TCP模式）等基于TCP的远端存储方案时，数据需要经过网络协议栈的处理，这增加了CPU的负担并可能导致较高的延迟，这些存储协议没有硬件加速的支持，因此在高I/O需求下性能表现不佳。

2.  方案介绍

2.1. 整体方案架构

为了应对KubeVirt虚拟机在网络与存储方面所遭遇的问题与挑战，本方案创造性地集成了DPU（数据处理单元）硬件，以下将详细阐述基于DPU卸载加速技术的KubeVirt虚拟机网络及存储解决方案的架构。