如何分析基于K8s的虛擬化技術(shù)Kube-virt

如何分析基于K8s的虛擬化技術(shù)Kube-virt，針對這個問題，這篇文章詳細介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

十年的薩迦網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。成都營銷網(wǎng)站建設(shè)的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整薩迦建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)從事“薩迦網(wǎng)站設(shè)計”,“薩迦網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。

根據(jù)Garnter的最新預(yù)測，到2022年將會有75%的生產(chǎn)應(yīng)用全部跑在容器環(huán)境之上。基于這個預(yù)測，其實至少還有25%的架構(gòu)由于技術(shù)原因或是認為原因都將仍然跑在舊的架構(gòu)之上，這其中虛擬機又會占據(jù)其中的大部分份額。所以在容器技術(shù)尤其是Kubernetes誕生之初，就已經(jīng)有開源的社區(qū)在為如何使用Kubernetes納管虛擬機作為一個重要的功能在開發(fā)和貢獻。

今天要介紹的主角就是Kube-virt，那么使用Kube-virt主要會幫我們解決以下兩個問題：

從技術(shù)層面，完全的虛擬機納管，可以完美遷移因為內(nèi)核版本過于陳舊以及語言問題而無法遷移到容器的部分應(yīng)用

從管理和運維層面，符合傳統(tǒng)的運維工作方式，以前的SSH 等運維方式可以完美復(fù)用

架構(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，生成對應(yīng)的virt-lancher pod，并維護CRD的狀態(tài)

• virt-handler

Virt-handler會以Daemonset形式部署在每個節(jié)點上，負責(zé)監(jiān)控節(jié)點上每個虛擬機實例狀態(tài)變化，一旦檢測到狀態(tài)變化，會進行響應(yīng)并確保相應(yīng)操作能達到所需（理想）狀態(tài)。

Virt-handler保持集群級VMI Spec與相應(yīng)libvirt域之間的同步；報告Libvirt域狀態(tài)和集群Spec的變化；調(diào)用以節(jié)點為中心的插件以滿足VMI Spec定義的網(wǎng)絡(luò)和存儲要求。

• virt-launcher

每個virt-lanuncher pod對應(yīng)著一個VMI， kubelet只是負責(zé)virt-lanuncher pod運行狀態(tài)，不會去關(guān)心VMI創(chuàng)建情況。

virt-handler會根據(jù)CRD參數(shù)配置去通知virt-lanuncher去使用本地libvirtd實例來啟動VMI， virt-lanuncher就會如果pid去管理VMI，pod生命周期結(jié)束，virt-lanuncher也會去通知VMI去終止。

每個virt-lanuncher pod對應(yīng)一個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的一對一對應(yīng)，做到如同容器一般去管理虛擬機，并且做到與容器一樣的資源管理、調(diào)度規(guī)劃，這個整體與企業(yè)Iaas關(guān)系不大，也方便企業(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)建虛擬機，并負責(zé)虛擬機生命周期管理

存儲

kubevirt 提供很多種存儲方式，存儲就決定了你使用虛擬機鏡像到底什么內(nèi)核、什么版本，以下主要講述我看到三種比較常用的形式

• registryDisk

定義image來創(chuàng)建虛擬機的root disk。virt-controller會在pod定義中創(chuàng)建registryVolume的container，container中的entry服務(wù)負責(zé) 將spec.volumes.registryDisk.image轉(zhuǎn)化為qcow2格式，路徑為pod根目錄。

kubevirt 提供了registryDIsk的基礎(chǔ)鏡像：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)絡(luò)

虛擬機網(wǎng)絡(luò)就是pod網(wǎng)絡(luò)，virt-launcher pod網(wǎng)絡(luò)的網(wǎng)卡不再掛有pod ip，而是作為虛擬機的虛擬網(wǎng)卡的與外部網(wǎng)絡(luò)通信的交接物理網(wǎng)卡，virt-launcher實現(xiàn)了簡單的單ip dhcp server，就是需要虛擬機中啟動dhclient，virt-launcher 服務(wù)會分配給虛擬機。

監(jiān)控

Kube-handler會去調(diào)用當(dāng)前節(jié)點下所有虛擬機的libvirt API，獲取虛擬機的監(jiān)控指標(biāo)，并提供metrics 接口，最后通過kubevirt-prometheus-metrics聚合所有節(jié)點的kube-handler的指標(biāo)數(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)部邏輯應(yīng)該只是重新調(diào)度virt-lanucher pod， 其中kubeirt-config可以對此進行遷移的相關(guān)限制，比如遷移的頻率（同時只能幾個節(jié)點進行遷移），遷移的網(wǎng)絡(luò)速率（因為可能實際到數(shù)據(jù)磁盤復(fù)制）， 通過VMIM也能查看到遷移進度。

Kubevirt VS Kata Container

當(dāng)然Kube-virt并不是目前唯一的可以在Kuberentes上實踐虛擬化的技術(shù)。我們把它也和目前比較流行的kata container做了一個對比，方便用戶根據(jù)實際情況來做選擇。

關(guān)于如何分析基于K8s的虛擬化技術(shù)Kube-virt問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。

分享題目：如何分析基于K8s的虛擬化技術(shù)Kube-virt
本文路徑：http://muchs.cn/article16/jpesdg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供服務(wù)器托管、微信小程序、網(wǎng)站策劃、品牌網(wǎng)站建設(shè)、App開發(fā)、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)