共計 3241 個字符，預計需要花費 9 分鐘才能閱讀完成。
如何分析基于 K8s 的虛擬化技術 Kube-virt，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
根據(jù) Garnter 的最新預測，到 2022 年將會有 75% 的生產(chǎn)應用全部跑在容器環(huán)境之上?；谶@個預測，其實至少還有 25% 的架構(gòu)由于技術原因或是認為原因都將仍然跑在舊的架構(gòu)之上，這其中虛擬機又會占據(jù)其中的大部分份額。所以在容器技術尤其是 Kubernetes 誕生之初，就已經(jīng)有開源的社區(qū)在為如何使用 Kubernetes 納管虛擬機作為一個重要的功能在開發(fā)和貢獻。
今天要介紹的主角就是 Kube-virt，那么使用 Kube-virt 主要會幫我們解決以下兩個問題：
從技術層面，完全的虛擬機納管，可以完美遷移因為內(nèi)核版本過于陳舊以及語言問題而無法遷移到容器的部分應用
從管理和運維層面，符合傳統(tǒng)的運維工作方式，以前的 SSH 等運維方式可以完美復用
架構(gòu)
為什么 kube-virt 可以做到讓虛擬機無縫的接入到 K8S？
首先，先給大家介紹一下它的整體架構(gòu)。
virt-api
kubevirt 是以 CRD 形式去管理 vm pod，virt-api 就是所有虛擬化操作的入口，包括常規(guī)的 CRD 更新驗證以及 vm start、stop
virt-controlller
virt-controller 會根據(jù) vmi CRD，生成對應的 virt-lancher pod，并維護 CRD 的狀態(tài)
virt-handler
Virt-handler 會以 Daemonset 形式部署在每個節(jié)點上，負責監(jiān)控節(jié)點上每個虛擬機實例狀態(tài)變化，一旦檢測到狀態(tài)變化，會進行響應并確保相應操作能達到所需（理想）狀態(tài)。
Virt-handler 保持集群級 VMI Spec 與相應 libvirt 域之間的同步；報告 Libvirt 域狀態(tài)和集群 Spec 的變化；調(diào)用以節(jié)點為中心的插件以滿足 VMI Spec 定義的網(wǎng)絡和存儲要求。
virt-launcher
每個 virt-lanuncher pod 對應著一個 VMI，kubelet 只是負責 virt-lanuncher pod 運行狀態(tài)，不會去關心 VMI 創(chuàng)建情況。
virt-handler 會根據(jù) CRD 參數(shù)配置去通知 virt-lanuncher 去使用本地 libvirtd 實例來啟動 VMI，virt-lanuncher 就會如果 pid 去管理 VMI，pod 生命周期結(jié)束，virt-lanuncher 也會去通知 VMI 去終止。
每個 virt-lanuncher pod 對應一個 libvirtd，virt-lanuncher 通過 libvirtd 去管理 VM 的生命周期，這樣做到去中心化，不再是以前虛擬機那套做法，一個 libvirtd 去管理多個 VM。
virtctl
virctl 是 kubevirt 自帶類似 kubectl 命令，它是越過 virt-lancher pod 這層去直接管理 vm，可以控制 vm 的 start、stop、restart。
總結(jié)：kubevirt 以 CRD 形式將 VM 管理接口接入到 kubernetes，通過一個 pod 去使用 libvirtd 管理 VM 方式，實現(xiàn) pod 與 VM 的一對一對應，做到如同容器一般去管理虛擬機，并且做到與容器一樣的資源管理、調(diào)度規(guī)劃，這個整體與企業(yè) Iaas 關系不大，也方便企業(yè)接入。
流程
上述架構(gòu)里其實已經(jīng)部分簡述了 VM 的創(chuàng)建流程，以下進行流程梳理：
1. K8S API 創(chuàng)建 VMI CRD 對象
2. virt-controller 監(jiān)聽到 VMI 創(chuàng)建時，會根據(jù) VMI 配置生成 pod spec 文件，創(chuàng)建 virt-launcher pods
3. virt-controller 發(fā)現(xiàn) virt-launcher pod 創(chuàng)建完畢后，更新 VMI CRD 狀態(tài)
4. virt-handler 監(jiān)聽到 VMI 狀態(tài)變更，通信 virt-launcher 去創(chuàng)建虛擬機，并負責虛擬機生命周期管理
存儲
kubevirt 提供很多種存儲方式，存儲就決定了你使用虛擬機鏡像到底什么內(nèi)核、什么版本，以下主要講述我看到三種比較常用的形式
registryDisk
定義 image 來創(chuàng)建虛擬機的 root disk。virt-controller 會在 pod 定義中創(chuàng)建 registryVolume 的 container，container 中的 entry 服務負責 將 spec.volumes.registryDisk.image 轉(zhuǎn)化為 qcow2 格式，路徑為 pod 根目錄。
kubevirt 提供了 registryDIsk 的基礎鏡像：registry-disk-v1alpha，根據(jù) Dockerfile 形式去創(chuàng)建虛擬機鏡像，以下是 window 鏡像 demo Dockerfile
`FROM kubevirt/registry-disk-v1alpha
COPY Windows---server-2012-datacenter-64bit-cn-syspreped---2018-01-15.qcow2 /disk/windows2012dc.img`這個最終我們構(gòu)建成鏡像名：windows2012dc:latest，最終在 CRD 表現(xiàn)形式是這樣的：
`kind: VirtualMachineInstance
...
spec:
domain:
devices:
disks:
\- disk:
bus: virtio
name: registrydisk
volumeName: registryvolume
... \- name: registryvolume
registryDisk:
image: windows2012dc:latest`PVC
PVC 是持久化存儲鏡像的形式，它會被掛在到 pod 中，且格式必須滿足 /disk/*.img, 這樣 kubevirt 才能夠?qū)崿F(xiàn)虛擬機存儲。
CDI
CDI 是 kubevirt 自己提供的一種形式，把 registryDisk 轉(zhuǎn)換為 PVC，這個需要消耗時間去講鏡像轉(zhuǎn)換為 PVC 持久化存儲下來。
網(wǎng)絡
虛擬機網(wǎng)絡就是 pod 網(wǎng)絡，virt-launcher pod 網(wǎng)絡的網(wǎng)卡不再掛有 pod ip，而是作為虛擬機的虛擬網(wǎng)卡的與外部網(wǎng)絡通信的交接物理網(wǎng)卡，virt-launcher 實現(xiàn)了簡單的單 ip dhcp server，就是需要虛擬機中啟動 dhclient，virt-launcher 服務會分配給虛擬機。
監(jiān)控
Kube-handler 會去調(diào)用當前節(jié)點下所有虛擬機的 libvirt API，獲取虛擬機的監(jiān)控指標，并提供 metrics 接口，最后通過 kubevirt-prometheus-metrics 聚合所有節(jié)點的 kube-handler 的指標數(shù)據(jù)，提供給 prometheus 使用。
遷移
通過 CRD：VirtualMachineInstanceMigration（VMIM）來實現(xiàn)動態(tài)遷移
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: vmi-fedora這種遷移形式其實并沒有指定遷移到哪些節(jié)點上，內(nèi)部邏輯應該只是重新調(diào)度 virt-lanucher pod，其中 kubeirt-config 可以對此進行遷移的相關限制，比如遷移的頻率（同時只能幾個節(jié)點進行遷移），遷移的網(wǎng)絡速率（因為可能實際到數(shù)據(jù)磁盤復制），通過 VMIM 也能查看到遷移進度。
Kubevirt VS Kata Container
當然 Kube-virt 并不是目前唯一的可以在 Kuberentes 上實踐虛擬化的技術。我們把它也和目前比較流行的 kata container 做了一個對比，方便用戶根據(jù)實際情況來做選擇。
關于如何分析基于 K8s 的虛擬化技術 Kube-virt 問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注丸趣 TV 行業(yè)資訊頻道了解更多相關知識。
