背景
Cloud Native
容器无疑已经成为新的云计算基础设施，企业私有云平台的建设重心，正在从虚拟化的计算、存储、网络的建设，转向构建以容器、微服务等为核心的云原生平台。不过值得注意的是，企业 IT 系统在进行容器化改造的过程中，由于历史遗留系统、技术债务、内核依赖等原因，基于虚拟机的应用在未来依然会广泛存在。企业的 IT 基础设施正在从单一的虚拟化架构逐步走向虚拟机+容器的混合架构，Gartner 预测到 2026 年将会有 75% 的私有化环境需要混合部署虚拟机和容器负载。
CNStack 虚拟化云服务
Cloud Native
在 CNStack 2.0 中，虚拟化服务以独立云服务的形态进行部署，即能复用 CNStack 平台与多集群服务提供的多租资源管理、统一网关、集群管理、多集群资源分发等基础能力，又能不失灵活性地独立演进与发布。
完整的虚拟机生命周期管理能力：支持开关机、重启、暂停、快照等操作。 虚拟机自运维能力
在浏览器通过 VNC、串口带外管理协议运维虚拟机。 快照与恢复：通过快照保存虚拟机磁盘在某一时刻的状态，数据丢失或异常时可快速恢复。 监控与告警：提供虚拟机 CPU、内存、磁盘 I/O、网络吞吐等关键运行指标的监控与告警。
管理虚拟机镜像
上传镜像，并按照租户控制资源的可见范围。 基于快照制作虚拟机镜像。
ARM 多架构、IPv6、虚拟机固定 IP、边缘虚拟机自治、虚拟机快照克隆等特性 虚拟机应用管理：CNStack 应用管理服务提供了对虚拟机应用的纳管功能，支持对虚拟机内应用的一站式托管以及服务治理、能力开放、应用监控、应用告警和应用防护等能力。
cnstack-virt-console 基于阿里云自研的 ALFA 微前端方案，cnstack-virt-console 以微前端应用的形式被 CNStack Console 前端页面插件化集成。即可以保证终端用户在交互体验上的一致，也可满足虚拟化服务前端应用自由演进、独立部署分发的灵活性。 cnstack-virt-api
KubeVirt
CDI
containerized-data-importer (CDI)[1]是 KubeVirt 社区下的一个子项目，拓展了管理虚拟机磁盘的 CRD，负责生产含有虚拟机磁盘数据的 PersistentVolume 供 KubeVirt 虚拟机消费，并可支持从 VMWare、oVirt 等外部虚拟化平台导入磁盘数据。
vmimage-controller
CNStack 云原生虚拟化
Cloud Native
相较于 OpenStack、VMWare vSphere 等传统的虚拟化平台来说，基于 KubeVirt 等云原生软件构建的 CNStack 云原生虚拟化平台有以下特点：
开放性
传统的虚拟化平台内往往集成了厂商提供的一整套网络、存储软件。而 Kubernetes 则基于 CSI、CNI 等规范提供了平台无关的资源抽象，基于 Kubernetes 构建的虚拟化平台可按照该规范自由对接各种类型的网络与存储资源，对客户来说避免了厂商锁定（vendor lock-in）的忧虑。
云原生的技术红利
毫无疑问云原生已经成为主流的技术领域，蓬勃发展的社区内囊括了监控、日志、安全、应用管理等丰富的软件生态。基于 Kubernetes 构建的虚拟化平台，统一的控制面与数据面使得虚拟机应用可以更便捷地享受云原生的技术红利。
文件：对应于 FileSystem VolumeMode 的 PV，PV 内只有一个磁盘镜像文件，QEMU 通过这种特殊格式的文件来模拟物理磁盘。 块设备：对应于 Block VolumeMode 的 PV，QEMU 直接通过块设备接口读取磁盘数据。由于 by-pass 了 PV 上的文件系统，具有更好的性能。
针对实际交付需求，CNStack 虚拟化服务支持本地与分布式存储两种场景：
本地存储：基于阿里巴巴开源的 open-local 容器存储插件，自动化节点本地磁盘的分配与调度，使得虚拟机可以灵活、低成本地使用本地存储资源。 分布式存储：基于阿里巴巴自研的 vCNS 云原生分布式存储软件，将 NVMe、SSD、HDD 等不同性能的磁盘进行分层地存储池化管理，为虚拟机提供了高性能、可靠的持久存储。
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
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
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
Upload Image
展望
Cloud Native
对于企业来说，部署管理虚拟机只是第一步，如何运维管理虚拟机内的应用还需要不少工作，针对于虚拟机应用的传统运维工具很难适配云原生的软件生态。CNStack 虚拟化服务后续除了会继续丰富虚拟机的运维能力之外，还期望能够为虚拟机内应用提供与容器应用相同的运维管理体验。
参考资料：
https://www.aliyun.com/activity/middleware/cnstack
CNCF OCM
CNCF KubeVirt
https://kubevirt.io/
open-local
hybridnet
相关链接
Cloud Native
https://github.com/kubevirt/containerized-data-importer
https://kubevirt.io/user-guide/architecture/#additional-services
http://kubevirt.io/api-reference/main/definitions.html#_v1_virtualmachine
http://kubevirt.io/api-reference/main/definitions.html#_v1_domainspec
[6] QEMU
https://www.qemu.org/
https://kubevirt.io/user-guide/virtual_machines/interfaces_and_networks/#frontend
https://opensource.com/article/19/7/what-golden-image
https://tekton.dev/
