Photo by Kevin Krüger on Unsplash
接續上一篇 在 K8S 上也能跑 VM！KubeVirt 儲存空間（上)，繼續分享如何實際掛載使用儲存空間。
KubeVirt的虛擬儲存媒體
前面所提到的各類儲存類型，都是所謂的後端連接到 VM image 等實際存取來源，接著就來看看前端，也就是掛載進 VM 內變成虛擬儲存媒體時的設定。
目前 KubeVirt 支援的虛擬媒體中，有支援光碟機(cdrom)、硬碟(disk)和iSCSI(LUN)，其中前兩者也是多數情境下最常使用的。在 KubeVirt 的定義中，都定義在 devices/disk 這個類別內。以下我們就用第一篇用來建立 VM的 YAML 檔案來當作範例：
在 disks 類別中，每一個虛擬儲存媒體都定義為一個陣列，定義媒體的類型、名稱及相關設定
- name：虛擬儲存媒體的名稱，只在 YAML 上定義，不會在 VM 內顯示
- cdrom/disk：定義儲存媒體為 cdrom 或是 disk。
- bus：定義這個儲存媒體在 VM 內是使用哪種虛擬硬體介面去連接，有分sata、virtio 與 scsi。沒有設定的話預設為 sata
- bootOrder：定義儲存媒體的開機順序，其數字從1開始，主要開機順序由這個參數來決定，而非媒體在 YAML 內的排列順序。須注意作為安裝系統的目標磁碟必須要設定此參數，否則部分安裝程式可能會視為該硬碟不可開機而拒絕安裝。
針對 bus 的部分，一般是使用 sata 居多，優點是相容性高，缺點是虛擬 I/O效能較差，因此做為系統碟使用的 disk 媒體，通常會建議使用 virtio 來加強效能；相反地，非 Linux 的作業系統普遍都不支援 virtio，若要讓 Windows能夠使用 virtio，必須在安裝作業系統時載入驅動程式，才可以抓到硬碟。另外，為了要讓安裝程式能夠順利開機，以及能夠載入 virtio 驅動程式給安裝程式，掛載 ISO 成虛擬光碟機時，bus 則一定要用 sata。
簡單來說，通常 bus 的建議設定如下：虛擬硬碟=virtio，虛擬光碟機=sata。
接著再來看 volume 部分。剛好可以看到三種儲存類型在 volume 上的寫法，分別為 persistentVolumeClaim、hostDisk 和 containerDisk。
與一般建立 Pod 時一樣，每一個 Volume 都有獨立的名稱，然後在 disks 區塊再去設定每一個虛擬媒體所對應的 Volume 名稱，以此進行對應掛載。
persistentVolumeClaim：只需要設定要使用的 PVC 名稱即可，注意 PVC 須和要建立的 VMI 處在同一個 namespace 下，若要存取不同 namespace 的PVC，則可以寫成
/<PVC名稱> 的形式，並且確保有給予其他namespace 可存取的權限。 hardDisk：hardDisk 的 type 可為 Disk 或 DiskOrCreate，前者是直接使用指令路徑的 image，後者則是指定路徑找不到 image 時自動建立新的 image。當需要建立新的 image 檔案時，則需要帶入 capacity 來指定要建立的 image 大小。
containerDisk：containerDisk 則是只需要輸入容器 image 的名稱即可，在此範例中，則是去掛載 KubeVirt 放在 Docker Hub 上的 virtio 驅動程式 image。
在 VM 建立時，每個虛擬媒體會根據定義的 Volume 名稱，掛載對應的來源。這便是 KubeVirt 在掛載儲存媒體時所使用的方式。
專屬於 KubeVirt 所使用的 containerDisk專屬於 KubeVirt 所使用的 containerDisk
在前面有提到 containerDisk 的類型，亦即將 VM image 打包進容器 image 內使用。
當建立 VM 時，Pod 會啟動兩個容器，其中一個容器會去掛載指定的容器 image 進開 VM 的容器內，再把裡面的 VM image 載入進 VM 內；由於只是把容器 image 內的 VM image 放進 Pod 內運行，因此 VM 刪除時，原先存放的資料也會消失。此類型通常用在大量部署且不需要保留資料、或者是做為掛載 ISO 時很常使用。缺點是沒辦法像 Openstack 的 VM 一樣能夠透過 resize 去擴增空間。
那麼 containerDisk 與一般的容器 image 結構差在哪邊呢？先說結論，大體結構上都是一樣的，只有裡面所存放的檔案有所差異。
一般的容器 image，除了會有該 image 的元數據、layer 清單等之外，還會包含該 image 的每一個 layer 層的封裝檔及該封裝資訊。若把其中一個 layer封裝檔解開看，可以發現每一個 layer 會是一個類似 Linux 的檔案結構，並且不同的 layer 只會存放有存在差異的檔案，只有基底 layer 才會有完整的檔案結構。
對於 containerDisk 而言就相對簡單。與一般容器 image 一樣， containerDisk 也有自己的 image 元數據及封裝資訊等，但若把 layer 內的封裝檔解開後，通常情況下可以發現只會有一個名為 disk 的資料夾，並且裡面存放 VM 或是 ISO 的 image；也就是說，containerDisk 裡面存放的並非完整的檔案結構，而是單純的運行用 image。
另外，KubeVirt 允許在使用 containerDisk 時，對於存放 VM/ISO image 的資料夾定義不同的名稱，只要在 YAML 內額外定義 image 的具體路徑即可。而這樣做的好處是，這允許管理者將常用的 VM/ISO image 都放進同一個containerDisk 內，透過同一個 containerDisk 來存取裡面不同的 VM/ISO image。若沒有定義，KubeVirt 預設會去讀取 /disk 路徑內的唯一 image。
由於沒辦法直接碰觸到裡面的 VM image，因此 containerDisk 類型的儲存沒辦法動態或是關機擴充 image 的大小，也就沒辦法調整主要儲存空間的容量。因此若規劃使用 containerDisk，則須事先規劃給應用或是使用者使用的預留空間，並且視需求另外使用 PVC 等來源掛載資料儲存空間。
同時，也因為上述的問題，使用 containerDisk 做為 root disk 的 VM，也無法做 Snapshot。
小結
本篇介紹了 KubeVirt 所使用的儲存類型與應用，可以發現大多數 KubeVirt 可使用的儲存類型，都是以 K8S 為基底下去運作，包括 PVC、emptyDir 等，另外包含了 containerDisk、HostDisk、以及可定義 VM 初始化內容的CloudInit 相關 Volume 類型等專讓 KubeVirt 使用的功能。儘管儲存部分與傳統 IaaS 服務的雲端環境相比，KubeVirt 還是有不小的差異與不足之處，但其已可以滿足小型或基本的使用需求。
–
雙子星雲端為 CNCF 會員，是 CNCF 所認證的 Kubernetes 服務提供商，在雲端技術擁有十多年以上的經驗，為台灣雲端技術早期領先者。目前為國家級 AI 雲的軟體及 Kubernetes 技術與服務提供商，更是諸多企業與單位導入容器與管理平台的最佳夥伴。
雙子星雲端已於近期推出 Kubernetes 管理平台 — Gemini Management Console，可搭配既有的產品 AI Console 與 Gemini API Gateway ，也提供企業諮詢與導入雲原生 Kubernetes、CI/CD 導入等相關技術服務，協助企業擁抱 Cloud Native，達到數位轉型的目標。
