Virtink：更轻量的 Kubernetes 原生虚拟化管理引擎
今天，我们很高兴地发布 Virtink 开源项目，一个更轻量的 Kubernetes 原生虚拟化管理引擎。
不同于 KubeVirt 项目，Virtink 并不考虑支持遗留硬件设备的模拟以及桌面应用场景能力，而是聚焦于在 Kubernetes 上运行现代化的云端虚拟化负载，因此Virtink 基于现代化的 Cloud Hypervisor1 实现，它可以在任何一个支持虚拟化的 CPU 平台上的 Kubernetes 中安装，以更安全轻量的方式支撑虚拟化负载。
同时，我们也发布 knest 开源项目，knest 是一个好用的命令行工具，利用 Virtink 的能力，可以非常方便地支撑 Kubernetes-in-Kubernetes 使用场景，让开发和运维部门不再需要传统虚拟化平台，便可方便地在裸金属上运行的 Kubernetes 上创建出任意多的 Kubernetes 集群。
背景
自从 Kubernetes 问世以来，它为云原生基础设施带来了革命性的变化。它强大的分布式调度能力、简单易用的集群资源抽象，以及丰富的第三方扩展能力使得其成为事实上的云原生平台标准，正加速吸引着更多的应用和中间件向其迁移。
然而，云计算以及更早的虚拟化时代下，大量的应用以虚拟机为载体。尽管在当今容器化的大浪潮下，一些应用进行了改造甚至重写以适应 Kubernetes 平台，但出于改造难度高或是工作量大等因素，仍有相当一部分的应用未被容器化，从而未能利用到 Kubernetes 强大能力。
此外，一些新开发的系统级别的应用，可能和宿主机需要使用不同的 kernel，无法跟宿主机共享 kernel，这些应用需要虚拟化能力的支撑来运行一个独立的 kernel。
这种容器和虚拟机共存但不能共管的情形增加了运维的难度和工作量，并且随着时间的推移这个问题会更加突出。让 Kubernetes 同时支持编排容器和虚拟机是一个可行的解决方案。
KubeVirt 项目作为这一领域的先驱者，这些年吸引了众多关注。KubeVirt 更多定位于支持传统虚拟化平台的能力。随着支撑的传统虚拟化平台功能的增多，代码复杂度越来越高，运行每个虚拟机的额外开销也很大。
Virtink 则完全面向现代化的云负载，结合最新的虚拟化技术进展，为用户提供更为轻量、更为安全的面向云负载的虚拟化管理引擎。
KubeVirt 面向传统虚拟化负载设计
为了更多地支持传统虚拟化平台的能力，KubeVirt 所使用的虚拟化软件为传统的 libvirt 配合 QEMU 的组合。KubeVirt 在每个虚拟机所在的 pod 内都需要运行独立的 libvirtd 和 launcher 进程，经观察，每个 libvirtd 进程的内存占用普遍在 30MB 以上，每个 launcher 进程的内存占用一般在 80MB 左右，也就是平均每个虚拟机的额外内存开销在 110MB 以上。当虚拟机达到一定数量时，这部分的内存开销会相当可观。
KubeVirt 支持的虚拟机镜像以 QCOW2 为主。QCOW2 的打包方式相对缓慢和繁琐，构建一个 QCOW2 镜像往往需要十几到几十分钟，且与容器的 Dockerfile 打包镜像的方式差别较大。
运行开销大、镜像打包慢，决定了 KubeVirt 是一个相对较重的虚拟化组件，它更适合承载传统虚拟化负载。
Virtink 面向现代化云端虚拟化负载设计
我们发现 Kubernetes 上的虚拟化需求通常是为了运行现代化的操作系统以及服务器端的负载，这些负载不需要像传统虚拟化一样需要类似 VNC 的桌面控制台，也不需要支持遗留的硬件设备模拟能力，但他们需要更少的额外资源开销，更安全的运行时环境以及更快的启动速度，Virtink 就是为运行这类现代化的云端虚拟化负载而设计的。
Virtink 是 Virtualization in Kuberentes 的缩写，它的初始设计目标如下：
采用 Kubernetes native 的架构，能部署在标准的 Kubernetes 集群之上，可通过 Kubernetes API 进行安装、使用和升级；
使用 Cloud Hypervisor 作为底层虚拟化管理器，只支持现代化的云负载，降低资源开销，保持代码简洁；
将 VM 和 pod 从网络和存储层面全打通，可与 Kuberntes 生态的 CNI 网络，CSI 存储及各类工具和产品结合使用；
完美支持 Kubernetes-in-Kubernetes 能力，让用户在 Kubernetes 时代，可以完全不依赖传统虚拟化平台（例如 VMware）来运行多套完全隔离的 Kuberenetes 集群，且拥有同样的运维便利性；
虚拟机镜像支持采用 Kubernetes 用户习惯的容器打包方式进行打包；
可运行在 x86 平台和 ARM 平台上。
Virtink 如何做到轻量？
利用轻量的 Cloud Hypervisor
Cloud Hypervisor1 是一个开源的 KVM 虚拟机管理器，由 Rust 编写，主要关注于支持现代化的云负载，提供最低限度的硬件模拟。它主打的优势是安全和轻量。由于提供了最小限度的硬件模拟，尽可能的减小了攻击面的同时也降低了内存开销。
无额外常驻进程开销
Virtink 不需要为每个 VM 运行 libvirtd 和 laucher 进程来管理 VM，完全去除掉了 VM 之外的任何开销。
Virtink 在 VM 运行前，启动一个前导进程 prerunner 做网络和虚拟机配置。该进程在完成这些配置后，会在 VM 启动时退出，因此没有长时间占用的内存和 CPU 开销。针对虚拟机的状态管理，则由每个节点上运行的 daemon 来处理。它会通过 Cloud Hypervisor 的 API socket，监控虚拟机的运行状态，并且在必要的时候下发虚拟机管理指令。
支持使用容器镜像作为虚拟机 rootfs
Cloud Hypervisor1 支持 direct kernel boot。在分别给定 kernel 和 rootfs 后，它能快速拉起虚拟机。这个功能的优势不仅仅在于虚拟机的启动速度，由于这里使用的 rootfs 仅要求是一个典型的根分区即可，并不需要像典型的启动盘一样划分出引导区、UEFI 分区等，因此 rootfs 的构建打包也相对容易很多。
基于 direct kernel boot 功能，Virtink 支持将容器镜像作为虚拟机的 rootfs，从而使得 rootfs 的打包构建能够完全利用 Docker 的工具链和生态，极大的加速和方便了虚拟机的构建和发布。下面就是一个用来构建 Ubuntu rootfs 的 Dockerfile 示例。
A Demo
完美支持 Kubernetes in Kubernetes
目前主流的公有云平台都提供了对 Kubernetes 的直接支持，使得在这些云平台上创建和运维一套 Kubernetes 集群变得十分轻松简单。然而，想要在私有的数据中心具备类似的能力，则需要付出相当的人力和物力。它一方面要求数据中心使用强大的分布式虚拟化平台，另一方面要求这个虚拟化平台对 Kubernetes 有强有力的支持，使得创建和运维 Kubernetes 集群是一件轻松简单的事情。
Virtink 的出现则使这个问题有了一个更简单轻量的解决方案。Virtink 提供的虚拟化能力可以很好地承载 Kubernetes 虚拟机集群的负载，即提供 Kubernetes as a service 的能力。并且由于 Virtink 相对轻量的特点，可以提供比 KubeVirt 更高的虚拟机运行密度，从而可以运行更多的 Kubernetes 节点。
我们同步开发了一个在 Kubernetes 集群之上创建嵌套 Kubernetes 集群的命令行工具 knest。借助这个工具，可以非常快捷地创建任意数量的嵌套 Kubernetes 集群，实现 Kubernetes as a service。
路线图
Virtink 现在是 v0.8 版本，已经支持了运行虚拟化负载的最小功能集合，例如支持 CNI 网络和 CSI 存储，并且支持了 x86 和 ARM 平台。在路线图上的功能有热迁移、主机 PCI 设备（SR-IOV 网卡、GPU 等）直通、vCPU 绑定、虚拟机磁盘热拔插等。
knest 现在是 v0.2 版本，支持了嵌套 Kubernetes 集群的创建和扩缩容等功能，后续版本的 knest 将持续增强易用性和集群运维功能。
Virtink2 和 knest3 项目托管在 Github 上，采用开放的 Apache License 2.0，您可以自由的使用和修改它们，同时欢迎您反馈 issue，提需求及参与到代码贡献中。
1. Cloud Hypervisor
https://www.cloudhypervisor.org/
2. Virtink
https://github.com/smartxworks/virtink
3. knest
https://github.com/smartxworks/knest
欢迎您扫描下方二维码，添加 SmartX 开源社区管理员微信，加入 Virtink 社区，与云原生专家和工程师们一起讨论 Virtink。或者您也可以通过邮箱（virtink@smartx.com）联系我们，沟通您的想法和问题。
点击阅读原文，了解 Virtink 开源项目更多信息。