Kubevirt Logo
KubeVirt 是一個 K8S 套件專案，隨著微服務與雲原生這幾年的發展，它被部分企業視為能夠促進雲原生更進一步的發展，以及讓傳統企業踏入容器化的第一步；另外在部分還使用傳統大型 VM 環境的企業，已漸漸考慮使用 KubeVirt 做為取代方案。
KubeVirt 起源於 2017 年，由 RedHat 所主導的「容器化 VM」解決方案，其構想是希望能夠在 K8S 環境上，建構一套可以透過容器來啟動 VM 的解決方案。之所以會有此構想，在於部分類型的服務與運作架構還不適合在容器下運作、或者是架構過於龐大或複雜，導致轉型成微服務相較困難，但又不希望同時具有兩種以上截然不同的運算叢集需要管理，所想出來的解決方案。
KubeVirt 除了具備傳統 VM 都有的功能外，還具有部分與容器接近的特性與功能，從而可以與 K8S 上的其他容器溝通互動。
目前已發展到 v0.53 版本，儘管主要還是以 RedHat 的 OpenShift 平台發展為開發目標，但目前也可以在其他已裝好 K8S 環境的 Linux 平台上獨立安裝，只要注意 KubeVirt 與 K8S 版本之間的配合即可，不論標準 K8S、miniKube、或是 MicroK8S 等都可以安裝。另除 OpenShift 外，部分廠商如Platform9 也加入了 KubeVirt 功能進自身平台中。
KubeVirt 運作架構
KubeVirt 主要由以下套件組成：
- virt-controller：對整個 KubeVirt 環境做管控
- virt-api：接收與發送 K8S API 以及 virt-handler 的請求與狀態回報等
- virt-handler：存在於 K8S node 內，主要是管理該節點上 VM
- virt-launcher：存在於 K8S node 內，主要運行 VM 時的 Pod 單元
可以注意到，KubeVirt 本身僅在於管理 VM 的狀態與尋找需提供 VM 要的資源，實際上資源來源、Scheduling 功能等等，本質上還是由 K8S 本體負責，包括 PV/PVC、StorageClass、網路、VM 所分配到的節點位置等；而在Scheduling 所包含的指派節點、使用專屬資源以及 Affinity 設定等，一樣是透過 match 等 API 定義，讓 K8S Scheduler 去做分配。
我們再切入到細一點。可能有人會問，那麼 KubeVirt 的 VM 建立跟一些也同樣容器化、如 Openstack 這種開源大型雲端叢集架構的差異在哪呢？畢竟一些 Openstack 部署專案如 Kolla、Triple-O 也同樣把服務都容器化了，這之間有什麼不同？
就 VM 運作架構上來說，KubeVirt 與運作架構容器化的 Openstack 的差異，在於：
Openstack 還是統一由單個容器集中管理所有 VM，包含 VMM 在內，都在同一個容器下運行，且因為純用 docker 去運行的環境大多數容器網路模式都是設定 host，因此在部署這類 Openstack 環境時，都要求實體系統上不得安裝 libvirt 等 VMM 套件，或者是在部署時自動偵測並移除。
KubeVirt 則是在 VM 啟動時，會單獨建立一個包含 VMM 的 Pod，並由這個 Pod 單獨運行指定的 VM，在建立時也會先找好需求的網路與儲存位置；若之後有其他 VM 需要開機，則會再啟動相對應的 Pod。換句話說，每一個VM 都會由獨立的 Pod 去服務。除了能夠確保每個 VM 的運作獨立性，就算實體系統另外安裝了 VMM 套件，也不影響 KubeVirt VM 的運作。
KubeVirt 儲存類型
KubeVirt 在儲存類型的支援上，也與 K8S 一樣，分為非永久儲存、永久儲存和定義儲存三類，並且大部分的類型跟 K8S 的方式是差不多的。
非永久儲存類：
- emptyDisk：建立一個空的 QCOW2 image，與 K8S 的 emptyDir 類似。
- containerDisk：前身名為為 registryDisk。顧名思義，是將 VM 映像檔打包變成容器 image 後，再透過這類 image 掛載使用。
永久儲存類：
- PersistentVolumeClaim：使用 K8S 的 PVC 來當作 VM 映像檔的儲存空間。
- DataVolume：PVC 的自動化衍伸，會自動下載並轉換 VM 映像檔後，再自動放入到 PVC 中，需要配合 CDI 套件使用。
- hostDisk：直接存取實體系統內已存在的 VM 映像檔。
定義儲存類：
- cloudInitNoCloud：作為一個 configMap 用的儲存類型，主要是用來寫入 cloud-init 設定，使 VM 在建立時自動設定預設的登入帳密和設定 IP 等功能。
這些儲存類型要如何使用，之後會有篇幅介紹。這邊只先說明，針對 PVC/DV 的部分，KubeVirt 強烈建議搭配 StorageClass 來使用，因此使用 KubeVirt 時，也建議自身的 K8S 環境先裝好符合自身需求的 CSI 套件並建立好 StorageClass。
KubeVirt 網路
由於 KubeVirt 本身共用不少 K8S 的功能，因此在網路上，自然也會共用 K8S 本身的網路，這其中又分為前端與後端兩類。前端指的是 VM 在 virt-launcher、也就是 Libvirt 設定連接的網路，後端指的是 virt-launcher 與 K8S 網路的連接，包括 K8S 預設的 CNI 網路。
KubeVirt 主要支援的「後端」網路類型有這兩種：
- Pod 網路：顧名思義，直接使用 K8S 上的預設 CNI 做為網路連線的基礎，類似 Openstack 的 Private Network 和 Neutron 的概念。KubeVirt 本身並沒有限制 K8S 上使用的 CNI 類型，舉凡 Calico、Flannel 等這些都可以支援。同時在這狀況下，也可以直接把 Service、Ingress 等 K8S 的網路設定功能套用在 KubeVirt 的 VM 上。
- Multus 網路：Multus 為 Intel 所建立的 K8S 網路架構開源專案，其目的是讓 K8S 能夠同時支援多種網路架構或 CNI，達到單一 Pod 可以介接多個網路的使用需求。以 Openstack 的角度而言，Multus 就類似於 K8S 上的 Provider Network，可透過 Multus 先建立好預設的 CNI 設定後，再設定容器或 VM 的Pod 去介接使用 Multus 所產生的網路。缺點是這類網路沒辦法透過 K8S 物件去做細部控管，只能從外部去控制。此外，還要預先建立好對應的連接，比如要使用 Multus 去做 Bridge 網路介接，就必須要先在實體系統上建立好對應的 Bridge。
在「前端」網路中，大多是使用 QEMU 及 Libvirt 提供的網路模式為主，種類如下：
- Bridge：讓 Libvirt 直接設定與後端網路做介接
- slirp：使用 QEMU 自己的 usermode 網路，QEMU 會建立一個 NAT 網路給 VM 使用。這種網路可讓 VM 上網，但不支援 ICMP 協定。
- sriov：將實體機器上已設定好 SR-IOV 功能的網卡 Pass-through 到 VM 內使用。
- masquerade：由 KubeVirt 自己透過 iptables 產生 NAT 網路，與 slirp 差異在可以限定哪些 Port 能做 Forwarding 連入，在建立 VM 時指定要開放的 Port 號碼，缺點是只支援 Pod 後端。
KubeVirt 官方建議，後端使用 Pod 模式的情況下，建議前端模式使用 masquerade；而後端使用 Multus 模式下，則依照需求使用適合的前端模式。
下一篇文章，將繼續介紹如何部署 Kubevirt!
