CNStack 虚拟化服务：实现虚拟机和容器资源的共池管理

背景

容器无疑已经成为新的云计算基础设施，企业私有云平台的建设重心，正在从虚拟化的计算、存储、网络的建设，转向构建以容器、微服务等为核心的云原生平台。不过值得注意的是，企业 IT 系统在进行容器化改造的过程中，由于历史遗留系统、技术债务、内核依赖等原因，基于虚拟机的应用在未来依然会广泛存在。企业的 IT 基础设施正在从单一的虚拟化架构逐步走向虚拟机+容器的混合架构，Gartner 预测到 2026 年将会有 75% 的私有化环境需要混合部署虚拟机和容器负载。

CNStack 虚拟化服务（cnstack-virtualization）基于以 CNCF KubeVirt 为代表的云原生虚拟化技术，用一套控制平面同时管理容器和虚拟机，实现容器与虚拟机的资源共池管理、灵活分配、统一调度。企业可将难以容器化的虚拟机应用无缝迁移到 CNStack 平台上，逐步实现 IT 系统的云原生化。

CNStack 虚拟化云服务

在 CNStack 2.0 中，虚拟化服务以独立云服务的形态进行部署，即能复用 CNStack 平台与多集群服务提供的多租资源管理、统一网关、集群管理、多集群资源分发等基础能力，又能不失灵活性地独立演进与发布。

CNStack 虚拟化服务在当前版本提供了如下能力，并会逐步在后续版本上线更多能力（如虚拟机灾备、虚拟机热迁移、虚拟机迁移工具等）：

完整的虚拟机生命周期管理能力：支持开关机、重启、暂停、快照等操作。
虚拟机自运维能力：

在浏览器通过 VNC、串口带外管理协议运维虚拟机。
快照与恢复：通过快照保存虚拟机磁盘在某一时刻的状态，数据丢失或异常时可快速恢复。
监控与告警：提供虚拟机 CPU、内存、磁盘 I/O、网络吞吐等关键运行指标的监控与告警。

管理虚拟机镜像

上传镜像，并按照租户控制资源的可见范围。
基于快照制作虚拟机镜像。

ARM 多架构、IPv6、虚拟机固定 IP、边缘虚拟机自治、虚拟机快照克隆等特性
虚拟机应用管理：CNStack 应用管理服务提供了对虚拟机应用的纳管功能，支持对虚拟机内应用的一站式托管以及服务治理、能力开放、应用监控、应用告警和应用防护等能力。

整体架构简介

cnstack-virt-console

基于阿里云自研的 ALFA 微前端方案，cnstack-virt-console 以微前端应用的形式被 CNStack Console 前端页面插件化集成。即可以保证终端用户在交互体验上的一致，也可满足虚拟化服务前端应用自由演进、独立部署分发的灵活性。

cnstack-virt-api

提供虚拟化云服务的管控 API，将 VirtualMachine、DataVolume、VMImage 等自定义资源的读写操作以 RESTful 接口的形式进行封装。与其他的管控 API 一样，由 CNStack IAM Gateway 组件统一提供用户认证、鉴权、API 审计等基础能力，向集群外提供服务。值得一提的是，cnstack-virt-api 基于 CNStack 多集群服务的 cluster-gateway 组件，实现了跨集群的资源分发。

KubeVirt

CNCF KubeVirt 拓展了管理运行虚拟机的 CRD，使得虚拟机资源可被视为 Kubernetes 集群的“一等公民”。KubeVirt 基于容器来管理运行 QEMU 虚拟机，提供了不同于容器的虚拟机生命周期管理接口，通过与标准的 CNI 容器网络插件和 CSI 容器存储插件对接，使得虚拟机可复用 Kubernetes 集群内的网络与存储资源。在 KubeVirt 社区版本的基础上，我们还为其拓展支持了 IPv6、GuestOS 监控、虚拟机固定IP、边缘虚拟机自治、虚拟机快照克隆等特性。

containerized-data-importer (CDI)[1]是 KubeVirt 社区下的一个子项目，拓展了管理虚拟机磁盘的 CRD，负责生产含有虚拟机磁盘数据的 PersistentVolume 供 KubeVirt 虚拟机消费，并可支持从 VMWare、oVirt 等外部虚拟化平台导入磁盘数据。

vmimage-controller

拓展了管理虚拟机镜像的 CRD。除了提供配置虚拟机所需要的 OS 元数据以外，还负责将镜像数据导入到集群，将集群内的虚拟机磁盘导出为镜像，并支持 ISO、QCOW2 等多种镜像格式，支持 OSS、HTTP、容器镜像等多种数据源。

CNStack 云原生虚拟化

相较于 OpenStack、VMWare vSphere 等传统的虚拟化平台来说，基于 KubeVirt 等云原生软件构建的 CNStack 云原生虚拟化平台有以下特点：

开放性

传统的虚拟化平台内往往集成了厂商提供的一整套网络、存储软件。而 Kubernetes 则基于 CSI、CNI 等规范提供了平台无关的资源抽象，基于 Kubernetes 构建的虚拟化平台可按照该规范自由对接各种类型的网络与存储资源，对客户来说避免了厂商锁定（vendor lock-in）的忧虑。

云原生的技术红利

毫无疑问云原生已经成为主流的技术领域，蓬勃发展的社区内囊括了监控、日志、安全、应用管理等丰富的软件生态。基于 Kubernetes 构建的虚拟化平台，统一的控制面与数据面使得虚拟机应用可以更便捷地享受云原生的技术红利。

KubeVirt 架构简介

下文着重介绍 KubeVirt 是如何基于 Kubernetes 解决网络、存储资源的虚拟化，以及虚拟机与容器是如何共享网络与存储资源，更多详细的 KubeVirt 架构介绍可见其官方文档[2]。

虚拟化技术的本质是对硬件设备的模拟，KubeVirt 提供了 VirtualMachine[3] CR 来描述虚拟机，VirtualMachine CR 的核心是通过 Domain[4] 类型来描述运行虚拟机所需的设备资源（熟悉 Libvirt[5] 的读者会发现这几乎就对应于 Libvirt Domain 的概念），最终通过 Libvirt 交由 QEMU[6] 模拟出虚拟机的硬件设备，也支持通过 Device Plugin 使用直通的宿主机 PCI 设备以降低设备模拟的开销。

KubeVirt 主要组件包括控制面的 virt-api 与 virt-controller，以 daemonset 部署的 virt-handler 负责管理配置节点上的虚拟机，以及实际运行 QEMU 虚拟机进程的 virt-launcher Pod，virt-launcher 承担了虚拟机存储网络与容器存储网络之间的桥梁。

虚拟机存储

虚拟机的磁盘数据存储在 virt-launcher Pod 挂载的 volume 中，volume 就交由各种 CSI 容器存储插件进行供给。KubeVirt 支持文件与块设备两种数据格式来存储磁盘数据：

文件：对应于 FileSystem VolumeMode 的 PV，PV 内只有一个磁盘镜像文件，QEMU 通过这种特殊格式的文件来模拟物理磁盘。
块设备：对应于 Block VolumeMode 的 PV，QEMU 直接通过块设备接口读取磁盘数据。由于 by-pass 了 PV 上的文件系统，具有更好的性能。

针对实际交付需求，CNStack 虚拟化服务支持本地与分布式存储两种场景：

本地存储：基于阿里巴巴开源的 open-local 容器存储插件，自动化节点本地磁盘的分配与调度，使得虚拟机可以灵活、低成本地使用本地存储资源。
分布式存储：基于阿里巴巴自研的 vCNS 云原生分布式存储软件，将 NVMe、SSD、HDD 等不同性能的磁盘进行分层地存储池化管理，为虚拟机提供了高性能、可靠的持久存储。

虚拟机网络

CNI 容器网络插件在容器的 network namespace 中创建 veth 网络设备（pod-nic）以供容器内进程使用，KubeVirt 提供了多种方式（Network Binding Mode[7]）连接 pod-nic 与 QEMU 虚拟机内的网络设备（VM-nic），Pod 之间的网络通信链路还是由 CNI 容器网络插件来管理。

bridge：pod-nic 与 VM-nic 直接通过 layer-2 bridge 连接，VM-nic 通过 DHCP 协议直接获取到 pod-nic 的 layer-3 IP，Pod 充当了交换机的角色。
masquerade：VM-nic 获取到的是本地 IP（只在 Pod 有效，一般固定为 10.0.1.2），VM-nic 发出/收到的流量都被 Pod 内的 iptables/nftables 规则 NAT 为 Pod IP 进行传输，Pod 充当了路由器的角色。
sriov, slirp, passt 等其他 KubeVirt Network Binding 就不一一介绍。

虚拟机固定 IP

KubeVirt 很大程度复用了容器网络来搭建虚拟机网络链路，这种架构保证了虚拟机和容器网络（包括 Service、Ingress、NetworkPolicy 等）之间的无缝衔接。但这也对虚拟机用户带来了一些使用体验上的差异，Pod IP 在重建前后往往会变化，但虚拟机用户却习惯于使用固定 IP 的虚拟机。CNStack 虚拟化服务基于由阿里巴巴开源的 hybridnet 容器网络插件，支持了虚拟机固定 IP 的能力，可以保证虚拟机所处 Pod 在重建后的 IP 与 Mac 地址保证不变。

虚拟机镜像（Golden Image）

对于个人电脑用户来说，相信一定不会陌生如何通过 ISO 光盘或者 U 盘来安装操作系统。虚拟机内操作系统（GuestOS）的安装则不太一样，各操作系统发行版一般会提供了两种格式：

ISO 光盘文件：最为常见，需要用户手动安装操作系统，可能还需要用户手动安装驱动，配置内核启动参数，安装 Cloud-init、GuestAgent、kdump 等 GuestOS 运维软件。
Golden Image：只有少部分发行版提供，免安装，开机即可使用，已经预先配置好了运维 GuestOS 所需各类软件，创建自 Golden Image 镜像的虚拟机也会具有更好的运维体验。例如 Ubuntu Cloud Image、阿里云官方提供的 ECS 镜像等。

由于大多数虚拟机用户缺乏构建 Golden Image[8] 的背景知识，一般只能提供 ISO 光盘文件（或者直接从发行版的官网下载）。我们基于 KubeVirt 与 Tekton CICD[9] 搭建了虚拟机镜像构建流水线（VMImage Pipeline），基于 ISO 光盘文件，自动构建出 Golden Image 并上传到 OSS 等集中式存储中，以供创建虚拟机。

VMImage Pipeline

上述 VMImage Pipeline 对应于一个 Tekton Pipeline，由若干 Tekton Task 组成。以构建 CentOS 的 Golden Image 为例，流程如下：

Install OS

CentOS、Fedora 等 Linux 发行版支持通过 kickstart[10] 自动化安装操作系统，ISO 内的安装程序启动后如果检测到 kickstart 配置文件，则会按照其配置自动执行安装程序。Windows 操作系统也支持通过 Sysprep[11] 实现类似的自动安装功能。值得一提的是，为了之后能通过 SSH 协议连接配置虚拟机，需要导入临时的用户信息。

Config OS

基于上一步安装完毕的系统盘 PVC 创建虚拟机，并启动临时 Pod 通过 SSH 协议连接到虚拟机，执行 bootstrap 脚本，配置 kernel 启动参数，安装 Cloud-init、QEMUGuestAgent 等软件。

Reset TempConfig

到这一步时，系统盘已经配置完毕了，但是之前虚拟机运行时在系统盘内残留了网卡的 mac 地址、ssh 连接记录等敏感信息，我们通过 virt-sysprep 工具抹去系统内的临时配置，生成一个干净的镜像文件。

Upload Image

将 PVC 内的磁盘文件上传到 OSS 等集中式存储中，之后销毁该 PVC。后续创建虚拟机时，可通过 CDI DataVolume HTTP Source 重新下载磁盘文件到新建虚拟机的 PVC 中。

展望

对于企业来说，部署管理虚拟机只是第一步，如何运维管理虚拟机内的应用还需要不少工作，针对于虚拟机应用的传统运维工具很难适配云原生的软件生态。CNStack 虚拟化服务后续除了会继续丰富虚拟机的运维能力之外，还期望能够为虚拟机内应用提供与容器应用相同的运维管理体验。

参考资料：

CNStack 产品官网:https://www.aliyun.com/activity/middleware/cnstack

CNCF OCM:https://open-cluster-management.io/

CNCF KubeVirt:https://kubevirt.io/

open-local:https://github.com/alibaba/open-local

hybridnet:https://github.com/alibaba/hybridnet

背景