DIY：使用 Kubernetes 建立你自己的雲端 (Part 2)
繼續我們關於如何僅使用 Kubernetes 生態系統建置您自己的雲端的系列文章。在先前的文章中，我們說明了如何準備基於 Talos Linux 和 Flux CD 的基本 Kubernetes 發行版。在本文中，我們將向您展示 Kubernetes 中的幾種不同虛擬化技術，並準備好在 Kubernetes 中執行虛擬機器所需的一切，主要是儲存和網路。
我們將討論 KubeVirt、LINSTOR 和 Kube-OVN 等技術。
但首先，讓我們解釋為什麼需要虛擬機器，以及為什麼您不能僅使用 Docker 容器來建置雲端？原因是容器未提供足夠的隔離等級。儘管情況逐年改善，但我們經常遇到允許逃脫容器沙箱並提升系統權限的漏洞。
另一方面，Kubernetes 最初並非設計為多租戶系統，這表示基本使用模式涉及為每個獨立專案和開發團隊建立單獨的 Kubernetes 叢集。
虛擬機器是在雲端環境中將租戶彼此隔離的主要方法。在虛擬機器中，使用者可以使用管理員權限執行程式碼和程式，但這不會影響其他租戶或環境本身。換句話說，虛擬機器允許實現硬多租戶隔離，並在租戶彼此不信任的環境中執行。
Kubernetes 中的虛擬化技術
有幾種不同的技術將虛擬化帶入 Kubernetes 世界：KubeVirt 和 Kata Containers 是最受歡迎的兩種。但您應該知道它們的工作方式不同。
Kata Containers 實作了 CRI (容器執行階段介面)，並透過在虛擬機器中執行標準容器，為其提供額外的隔離等級。但它們在同一個單一 Kubernetes 叢集中運作。
圖表顯示透過使用 Kata Containers 在虛擬機器中執行容器來確保容器隔離的方式
KubeVirt 允許使用 Kubernetes API 執行傳統虛擬機器。KubeVirt 虛擬機器作為容器中的常規 Linux 程序執行。換句話說，在 KubeVirt 中，容器用作執行虛擬機器 (QEMU) 程序的沙箱。從下圖中可以清楚地看到這一點，方法是查看 KubeVirt 中虛擬機器的即時移轉是如何實作的。當需要移轉時，虛擬機器會從一個容器移動到另一個容器。
圖表顯示 KubeVirt 中虛擬機器從一個容器到另一個容器的即時移轉
還有一個替代專案 - Virtink，它使用 Cloud-Hypervisor 實作輕量級虛擬化，最初專注於使用 Cluster API 執行虛擬 Kubernetes 叢集。
考慮到我們的目標，我們決定使用 KubeVirt 作為該領域最受歡迎的專案。此外，我們擁有廣泛的專業知識，並且已經為 KubeVirt 做了許多貢獻。
KubeVirt 易於安裝，並允許您使用 containerDisk 功能立即執行虛擬機器 - 這允許您直接將 VM 映像作為 OCI 映像從容器映像登錄檔儲存和分發。具有 containerDisk 的虛擬機器非常適合建立 Kubernetes 工作節點和其他不需要狀態持久性的 VM。
為了管理持久性資料，KubeVirt 提供了一個單獨的工具，容器化資料匯入器 (CDI)。它允許複製 PVC 並使用來自基礎映像的資料填充它們。如果您想為您的虛擬機器自動佈建持久性磁碟區，則 CDI 是必要的，並且它也是 KubeVirt CSI 驅動程式所必需的，該驅動程式用於處理來自租戶 Kubernetes 叢集的持久性磁碟區宣告。
但首先，您必須決定將這些資料儲存在哪裡以及如何儲存。
Kubernetes VM 的儲存
隨著 CSI (容器儲存介面) 的引入，各種與 Kubernetes 整合的技術變得可用。事實上，KubeVirt 充分利用了 CSI 介面，使虛擬化的儲存選擇與 Kubernetes 本身的儲存選擇緊密結合。但是，有一些細微差別需要您考慮。與通常使用標準檔案系統的容器不同，區塊裝置對於虛擬機器更有效率。
雖然 Kubernetes 中的 CSI 介面允許請求兩種磁碟區類型：檔案系統和區塊裝置，但務必驗證您的儲存後端是否支援此功能。
為虛擬機器使用區塊裝置消除了對額外抽象層 (例如檔案系統) 的需求，這使其效能更高，並且在大多數情況下可以啟用 ReadWriteMany 模式。此模式允許從多個節點同時存取磁碟區，這是啟用 KubeVirt 中虛擬機器即時移轉的關鍵功能。
儲存系統可以是外部的或內部的 (在超融合基礎架構的情況下)。在許多情況下，使用外部儲存使整個系統更穩定，因為您的資料與運算節點分開儲存。
圖表顯示外部資料儲存與運算節點的通訊
外部儲存解決方案在企業系統中通常很受歡迎，因為此類儲存通常由外部供應商提供，他們負責其運作。與 Kubernetes 的整合僅涉及安裝在叢集中的一個小組件 - CSI 驅動程式。此驅動程式負責在此儲存中佈建磁碟區，並將其連接到 Kubernetes 執行的 Pod。但是，此類儲存解決方案也可以使用純開放原始碼技術來實作。流行的解決方案之一是由 democratic-csi 驅動程式支援的 TrueNAS。
圖表顯示在運算節點上執行的本機資料儲存
另一方面，超融合系統通常使用本機儲存 (當您不需要複寫時) 和軟體定義儲存來實作，軟體定義儲存通常直接安裝在 Kubernetes 中，例如 Rook/Ceph、OpenEBS、Longhorn、LINSTOR 等等。
圖表顯示在運算節點上執行的叢集式資料儲存
超融合系統有其優勢。例如，資料本地性：當您的資料在本機儲存時，存取此類資料的速度更快。但也有缺點，因為此類系統通常更難管理和維護。
在 Ænix，我們希望提供一個隨時可用的解決方案，該解決方案可以無需購買和設定額外的外部儲存即可使用，並且在速度和資源利用率方面是最佳的。LINSTOR 成為了該解決方案。經過時間考驗且在業界廣受歡迎的技術 (例如 LVM 和 ZFS 作為後端) 使人們對資料的安全儲存充滿信心。基於 DRBD 的複寫速度非常快，並且消耗少量的運算資源。
為了在 Kubernetes 中安裝 LINSTOR，有 Piraeus 專案，該專案已經提供了一個隨時可用的區塊儲存，可與 KubeVirt 一起使用。
Kubernetes VM 的網路
儘管具有相似的介面 - CNI，但 Kubernetes 中的網路架構實際上更複雜，通常由許多彼此不直接連接的獨立組件組成。事實上，您可以將 Kubernetes 網路分成四層，如下所述。
節點網路 (資料中心網路)
節點彼此互連的網路。此網路通常不由 Kubernetes 管理，但它很重要，因為沒有它，任何東西都無法運作。實際上，裸機基礎架構通常具有多個此類網路，例如，一個用於節點到節點的通訊，第二個用於儲存複寫，第三個用於外部存取等。
圖表顯示節點網路 (資料中心網路) 在 Kubernetes 網路架構中的作用
節點之間實體網路互動的配置超出了本文的範圍，因為在大多數情況下，Kubernetes 利用了現有的網路基礎架構。
Pod 網路
這是由您的 CNI 外掛程式提供的網路。CNI 外掛程式的任務是確保叢集中所有容器和節點之間的透明連線。大多數 CNI 外掛程式實作一個平面網路，從該網路中分配單獨的 IP 位址區塊以在每個節點上使用。
圖表顯示 Pod 網路 (CNI 外掛程式) 在 Kubernetes 網路架構中的作用
實際上，您的叢集可以有多個由 Multus 管理的 CNI 外掛程式。這種方法通常用於基於 KubeVirt 的虛擬化解決方案 - Rancher 和 OpenShift。主要 CNI 外掛程式用於與 Kubernetes 服務整合，而其他 CNI 外掛程式用於實作私有網路 (VPC) 以及與資料中心的實體網路整合。
預設 CNI 外掛程式可用於連接橋接器或實體介面。此外，還有專門的外掛程式，例如 macvtap-cni，它們旨在提供更高的效能。
在 Kubernetes 中運行虛擬機器時，另一個需要注意的方面是 IPAM（IP 位址管理）的需求，特別是對於 Multus 提供的輔助介面而言。這通常由您基礎架構中運行的 DHCP 伺服器來管理。此外，虛擬機器的 MAC 位址分配可以通過 Kubemacpool 進行管理。
雖然在我們的平台中，我們決定另闢蹊徑，完全依賴 Kube-OVN。這個 CNI 外掛程式基於 OVN（開放虛擬網路），OVN 最初是為 OpenStack 開發的，它為 Kubernetes 中的虛擬機器提供了完整的網路解決方案，具備用於管理 IP 和 MAC 位址的自訂資源，支援在節點之間保留 IP 位址的即時遷移，並能夠建立 VPC 以實現租戶之間的實體網路隔離。
在 Kube-OVN 中，您可以將單獨的子網路分配給整個命名空間，或者使用 Multus 將它們連接為額外的網路介面。
服務網路
除了 CNI 外掛程式之外，Kubernetes 還具有服務網路，這主要是服務發現所必需的。與傳統虛擬機器相反，Kubernetes 最初設計為運行具有隨機位址的 Pod。而服務網路提供了一個方便的抽象概念（穩定的 IP 位址和 DNS 名稱），它始終會將流量導向正確的 Pod。儘管雲端中的虛擬機器的 IP 通常是靜態的，但在雲端中，虛擬機器也常使用相同的方法。
一個圖表，顯示了服務網路（服務網路外掛程式）在 Kubernetes 網路架構中的作用
Kubernetes 中服務網路的實作由服務網路外掛程式處理。標準實作稱為 kube-proxy，並在大多數叢集中使用。但是現在，此功能可能會作為 CNI 外掛程式的一部分提供。Cilium 專案提供了最先進的實作，它可以以 kube-proxy 替換模式運行。
Cilium 基於 eBPF 技術，該技術可以有效地卸載 Linux 網路堆疊，從而提高效能和安全性，與基於 iptables 的傳統方法相比更具優勢。
實際上，Cilium 和 Kube-OVN 可以輕鬆地 整合，以提供統一的解決方案，為虛擬機器提供無縫的多租戶網路，以及先進的網路策略和組合的服務網路功能。
外部流量負載平衡器
在這個階段，您已經擁有在 Kubernetes 中運行虛擬機器所需的一切。但實際上還有一件事。您仍然需要從您的叢集外部訪問您的服務，而外部負載平衡器將幫助您組織這一切。
對於裸機 Kubernetes 叢集，有幾個可用的負載平衡器：MetalLB、kube-vip、LoxiLB，此外 Cilium 和 Kube-OVN 也提供了內建的實作。
外部負載平衡器的作用是提供一個外部可用的穩定位址，並將外部流量導向服務網路。服務網路外掛程式會像往常一樣將其導向您的 Pod 和虛擬機器。
一個圖表，顯示了外部負載平衡器在 Kubernetes 網路架構中的作用
在大多數情況下，在裸機上設定負載平衡器是通過在叢集內節點上建立浮動 IP 位址，並使用 ARP/NDP 或 BGP 協定在外部宣告它來實現的。
在探索了各種選項之後，我們認為 MetalLB 是最簡單且最可靠的解決方案，儘管我們並未嚴格強制僅使用它。
另一個好處是，在 L2 模式下，MetalLB speakers 通過使用 memberlist 協定發送執行活性探測來持續檢查其鄰居的狀態。這使得故障轉移能夠獨立於 Kubernetes 控制平面工作。
結論
這總結了我們對 Kubernetes 中虛擬化、儲存和網路的概述。此處提到的技術在 Cozystack 平台上可用且已預先配置，您可以在該平台上無限制地試用它們。
在下一篇文章中，我將詳細介紹如何在此基礎上實現只需單擊按鈕即可佈建功能齊全的 Kubernetes 叢集。