今天，我們很高興地釋出 Virtink 開源項目，一個更輕量的 Kubernetes 原生虛拟化管理引擎。
不同于 KubeVirt 項目，Virtink 并不考慮支援遺留硬體裝置的模拟以及桌面應用場景能力，而是聚焦于在 Kubernetes 上運作現代化的雲端虛拟化負載，是以Virtink 基于現代化的 Cloud Hypervisor 實作，它可以在任何一個支援虛拟化的 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 Hypervisor 是一個開源的 KVM 虛拟機管理器，由 Rust 編寫，主要關注于支援現代化的雲負載，提供最低限度的硬體模拟。它主打的優勢是安全和輕量。由于提供了最小限度的硬體模拟，盡可能的減小了攻擊面的同時也降低了記憶體開銷。
無額外常駐程序開銷
Virtink 不需要為每個 VM 運作 libvirtd 和 laucher 程序來管理 VM，完全去除掉了 VM 之外的任何開銷。
Virtink 在 VM 運作前，啟動一個前導程序 prerunner 做網絡和虛拟機配置。該程序在完成這些配置後，會在 VM 啟動時退出，是以沒有長時間占用的記憶體和 CPU 開銷。針對虛拟機的狀态管理，則由每個節點上運作的 daemon 來處理。它會通過 Cloud Hypervisor 的 API socket，監控虛拟機的運作狀态，并且在必要的時候下發虛拟機管理指令。
支援使用容器鏡像作為虛拟機 rootfs
Cloud Hypervisor 支援 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 将持續增強易用性和叢集運維功能。
Virtink 和 knest 項目托管在 Github 上，采用開放的 Apache License 2.0，您可以自由的使用和修改它們，同時歡迎您回報 issue，提需求及參與到代碼貢獻中。
歡迎您過搜尋手機号 13681356484 添加 SmartX 開源社群管理者微信，加入 Virtink 社群，與雲原生專家和工程師們一起讨論 Virtink。或者您也可以通過郵箱（[email protected]）聯系我們，溝通您的想法和問題。
點選了解 Virtink 開源項目更多資訊。