網管人雜誌
本文刊載於 網管人雜誌第 172 期 - 2020 年 5 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。本文目錄
前言vSphere 7 亮眼特色功能
vSphere 整合並內建 Kubernetes
DRS 自動化調度機制再升級
更彈性的硬體直通機制
重構 vSphere vMotion 即時遷移機制
支援多重因素身份驗證機制
實作演練 vSphere 7 with Kubernetes
部署 Supervisor Kubernetes 叢集
部署和管理名稱空間
結語
前言
醞釀已久的全新 vSphere 7 解決方案，終於在 2020 年 3 月 10 日由 VMware 官方正式發佈，同時 VMware CEO Pat Gelsinger 更在線上會議中表示，全新推出的 vSphere 7 擁抱並且內建 Kubernetes。因此，管理人員無須再費心要如何建構 Kubernetes 叢集和高可用性環境，因為 vSphere 7 即可直接部署和管理 Kubernetes 叢集。全新推出的 vSphere 7 基礎架構平台，便是之前開發代號 Project Pacific 的正式版本。
簡單來說，當企業和組織採用 vSphere 7 建構虛擬化基礎架構時，便能同時打造具備 VM 虛擬主機和 Kubernetes 叢集的高可用性環境（如圖 1 所示），因為在 vSphere 7 當中已經將 Kubernetes API 直接原生整合至 vSphere API 當中，幫助企業和組織內的 Dev 開發人員透過 Kubernetes API 部署和管理容器，而 Ops 管理人員仍可採用過去管理 VM 虛擬主機的方式，直接管理 Kubernetes 叢集以及容器。
圖 1、vSphere 7 新增亮眼特色功能示意圖
vSphere 7 亮眼特色功能
vSphere 整合並內建 Kubernetes
過去的 vSphere 解決方案，對於管理人員說便是圍繞在以 VM 虛擬主機工作負載為中心，透過 vCenter Server 管理平台調度運作於 ESXi 虛擬化平台中，不同工作任務和屬性的 VM 虛擬主機資源，確保營運服務高可用性。然而，新興的應用模式已經改為以「容器」（Container）為主，並且搭配大勢所趨的 Kubernetes 容器調度管理平台。雖然傳統的 vSphere 基礎架構，也支援運作各種 Kubernetes 解決方案和容器等工作負載，然而企業和組織原有的 Ops 營運團隊和管理工具，卻無法妥善且快速的處理各種容器應用上的疑難雜症。現在，全新打造的 vSphere 7 除了將 Kubernetes 內建於其中之外，更將 vSphere 7 建構成可以承載和調度任何工作負載的基礎架構，無論是傳統的 VM 虛擬主機、HA 高可用性機制……等，或者是新興的 Container、Pod、Namespace、Persistent Volume……等。
因此，企業和組織內的 Dev 開發人員和 Ops 管理人員，可以在 vSphere 基礎架構中看到相同的運作環境，並且各自進行管理和部署作業加速協同運作邁向 DevOps。舉例來說，Dev 開發人員可以採用 YAML 檔案，透過 Kubernetes API 管理和調度容器的生命週期，Ops 管理人員也可以採用 YAML 檔案，透過 vSphere API 管理和調度 VM 虛擬主機的生命週期，確保大家採用相同的 YAML 檔案格式和 API 進行管理和部署作業。
現在，在 vSphere 7 運作架構中，管理人員可以透過 Kubernetes 內的「Namespace」機制，同時管理和部署舊有以 VM 虛擬主機為主的應用程式和服務，以及新興以容器為主的應用程式和服務（如圖 2 所示）。在一個新增的 Namespace 當中，同時承載傳統應用程式的 VM 虛擬主機，以及由多台 VM 虛擬主機組成的資料庫叢集，並且以容器方式運作的現代化應用程式，搭配無伺服器架構的 Serverless 服務，而管理人員可以輕鬆針對整個 Namespace 進行管控，例如，硬體資源的使用率、網路資料傳輸安全性、工作負載可用性、機敏資料存取管控……等。
管理人員可以將「Namespace」機制想像為資料夾，它可以承載各種資源和不同的工作負載，例如，VM 虛擬主機、容器、Serverless……等。
圖 2、透過 Namespace 機制打造以應用程式為中心示意圖
DRS 自動化調度機制再升級
在傳統的 vSphere 虛擬化基礎架構中，vSphere DRS（Distributed Resource Scheduler）自動化調度機制，主要用於調度 VM 虛擬主機工作負載。現在，全新推出的 vSphere 7 基礎架構，不僅運作 VM 虛擬主機也同時運作許多 Pods 和容器，因此 VMware 針對 DRS 自動化調度機制進行功能增強，以便最佳化調度 VM 虛擬主機和容器等工作負載。過去的 vSphere DRS 機制，是透過「整體叢集標準差模型」（Cluster-wide standard deviation model）機制，針對 vSphere 叢集中 ESXi 成員主機之間的工作負載進行資源的負載平衡作業。
現在，增強後的 vSphere DRS 機制，不在將資源負載平衡的重點放在「ESXi 成員主機」身上，而是將焦點放在「VM 虛擬主機」身上，當 vSphere 叢集啟用 vSphere DRS 機制後，將會「每分鐘」計算 ESXi 成員主機上運作的 VM 虛擬主機得分「VM DRS Score」（如圖 3 所示），然後判斷透過 vMotion 機制遷移 VM 虛擬主機後，對於其它 VM 虛擬主機的影響為何，以達成更細緻更優化的資源使用率。
圖 3、新版 vSphere DRS 自動化調度機制示意圖
更彈性的硬體直通機制
在過去的 vSphere 基礎架構中，當 ESXi 主機配置支援硬體卸載機制時，可以透過 DirectPath I/O 硬體直通機制（如圖 4 所示），指派給 VM 虛擬主機並寫入 .vmx 組態設定檔案中以便獲得最佳效能，然而啟用 DirectPath I/O 機制的 VM 虛擬主機，雖然獲得硬體最佳使用效能，但是對於 VM 虛擬主機的彈性則有所影響，例如，無法透過 vSphere DRS 進行自動化調度，無法受到 vSphere HA 高可用性機制的保護。
圖 4、DirectPath I/O 硬體直通機制示意圖
雖然，從 vSphere 6.7 Update 1 版本開始，支援採用 vGPU 技術的 VM 虛擬主機能夠執行 vMotion 遷移和快照功能（如圖 5 所示），但仍無法支援 vSphere DRS 自動化調度機制，以及 vSphere HA 高可用性機制。
圖 5、vSphere 6.7 Update 1 版本開始支援 vGPU 虛擬主機 vMotion 和快照
現在，全新 vSphere 7 運作架構中，採用新式機制稱為「可指派硬體」（Assignable Hardware）。簡單來說，採用新式 Dynamic DirectPath I/O 機制，不在鎖定只能運作於特定 ESXi 主機上，舉例來說，在 vSphere 叢集中共有 100 台 NVIDIA V100 GPU 的虛擬主機，當啟用 vSphere DRS 機制並啟動使用 vGPU 的 VM 虛擬主機時，將會自動尋找可提供 GPU 資源的 ESXi 成員主機，然後將 VM 虛擬主機進行註冊並使用的動作，即便 ESXi 成員主機發生故障觸發 vSphere HA 高可用性機制後，也會自動尋找其它可用 GPU 資源的 ESXi 成員主機，將受影響的 VM 虛擬主機重新啟動並繼續使用 vGPU 資源。
VM 虛擬主機必須採用最新「VM Hardware version 17」，才能支援 Assignable Hardware 彈性機制。
重構 vSphere vMotion 即時遷移機制
與前面提到的 vSphere DRS 調度機制一樣，為了確保 vSphere vMotion 即時遷移機制，能夠更適合新興的應用方式，VMware 官方整個重構 vSphere vMotion 即時遷移機制。舉例來說，對於 SAP HANA 和 Oracle 資料庫這種大型規模的 VM 虛擬主機，透過傳統的 vSphere vMotion 即時遷移機制進行搬移，由於大型規模 VM 虛擬主機龐大的 vCPU 和記憶體空間，並且「頁面追蹤」（Page Tracing）機制是套用在所有 vCPU（如圖 6 所示），並採用「4 KB Pages」小型資料區塊傳輸 vRAM 虛擬記憶體空間，因此除了容易造成 vMotion 遷移時間過長的情況，也有可能影響應用程式的運作。
圖 6、傳統 vSphere vMotion 即時遷移頁面追蹤技術示意圖
現在，全新 vSphere 7 運作架構中，採用重構後的 vSphere vMotion 機制，有效解決大型規模 VM 虛擬主機即時遷移的難題。首先，在 vCPU 虛擬處理器運算資源遷移的部份採用「專用」（Dedicated）的頁面追蹤機制，確保進行 vMotion 遷移時不會影響應用程式的運作（如圖 7 所示）。
圖 7、重構後的 vSphere vMotion 即時遷移頁面追蹤技術示意圖
在 vRAM 虛擬記憶體遷移的部份，改為採用「1 GB Pages」資料區塊進行傳輸並搭配其它最佳化機制，例如，Memory Pre-Copy、Switchover……等。舉例來說，在過去舊版的 vSphere 環境中，遷移 24 TB vRAM 虛擬記憶體空間需要 768 MB Bitmap，預計遷移時間需要花費「2 秒鐘」，重構後的 vSphere vMotion 則僅需要「175 毫秒」即可完成（如圖 8 所示），確保大型規模 VM 虛擬主機切換至不同 ESXi 主機時，能夠由幾秒鐘的時間縮短至幾毫秒。
圖 8、重構後的 vSphere vMotion 切換 ESXi 主機時間由幾秒鐘縮短至幾毫秒
在 VMware 官方測試結果中，採用安裝 Oracle 資料庫的 VM 虛擬主機，並配置「72 vCPU 和 512 GB vRAM」大型規模虛擬硬體資源，然後採用傳統 vSphere vMotion 和重構後的 vSphere vMotion，遷移 Oracle 虛擬主機，並在遷移期間透過 Hammer DB 進行工作負載模擬。簡單來說，重構後的 vSphere vMotion 除了更快速遷移完成之外，在遷移期間 Oracle 資料庫的 Commits 數量相較於舊版 vMotion 也高出許多（如圖 9 所示）。
圖 9、傳統和重構後的 vSphere vMotion 遷移大型 VM 虛擬主機測試結果
支援多重因素身份驗證機制
目前，對於提升使用者身分驗證機制安全性來說，最簡單的方式就是良好的密碼原則之外，搭配「多重因素身份驗證」（MultiFactor Authentication，MFA），然而目前能實作 MFA 多重因素身份驗證的方法太多，無法將所有 MFA 實作方式整合至 vCenter Server。因此，VMware 針對 MFA 多重因素身份驗證的解決方案，是支援開放式身份驗證和授權標準，例如，OAuth2、OIDC……等。在 vSphere 7 運作環境中，透過「識別身份同盟」（Identity Federation）讓 vCenter Server 管理平台（如圖 10 所示），能夠和使用者身分驗證機制供應商進行溝通，達到簡化 vSphere 管理人員法規審核範圍，同時也支援更多不同的 MFA 多重因素身份驗證，例如，熱門的 ADFS（Active Directory Federation Services）。
圖 10、vCenter Server 支援 MFA 多重因素身份驗證流程示意圖
此外，在 vSphere 7 運作環境中，還新增「vTA（vSphere Trust Authority）」信任授權機制，透過單獨管理的小型 vSphere 叢集建立硬體式根授權，當 ESXi 主機底層 x86 伺服器透過 UEFI 安全性機制啟動時，搭配「信賴平台模組」（Trusted Platform Module，TPM）進行驗證，確保 x86 伺服器採用正確且通過驗證程序的軟體（如圖 11 所示）。
圖 11、vTA（vSphere Trust Authority）信任授權機制運作架構示意圖
一旦 ESXi 虛擬化平台順利啟動後，便能運作加密 VM 虛擬主機，確保 VM 虛擬主機內的機敏資料外洩，並且透過 REST API 用於從 VMCA（VMware Certificate Authority），執行憑證自動續訂的動作，簡化 ESXi 管理憑證的麻煩。
實作演練 vSphere 7 with Kubernetes
由於，在撰寫本文時官方正式的 vSphere ESXi 7.0 和 vCenter Server 7.0 印象檔仍未釋出，但是有興趣的 Ops 管理人員和 Dev 開發人員，仍然可以透過 VMware HOL（Hands-on-Labs）進行 vSphere 7 with Kubernetes 實作演練（如圖 12 所示）。有興趣的讀者，可以網路尋找關鍵字 VMware Hands-on Labs - HOL-2013-01-SDC - vSphere 7 with Kubernetes- Lightning Lab 即可立即進行實作演練。
圖 12、vSphere with Kubernetes 運作架構示意圖
在開始實作演練之前，我們先了解 vSphere 7 新世代的叢集架構「Supervisor Kubernetes Cluster」，以便後續進行實作時能夠有更深入的體驗。簡單來說，在 vSphere 7 中的 Supervisor Kubernetes 叢集，由於已經原生整合至 ESXi 虛擬化平台中，所以不像傳統由 Linux 所建構的 Kubernetes 叢集採用 Kubelet 指令進行管理作業，而是在 ESXi 虛擬化平台中除了原有的 hostd 服務之外，還會常駐有「Spherelet」用來管理其上運作的 Pod 和容器。
此外，在 Supervisor Kubernetes 叢集中，每個在 ESXi 主機內運作的 Pod 及 Pod 內的容器，都會在個別的「CRX 虛擬主機」內運作，以便達到不同的 Pod 和容器的最大隔離性，有效減少運作的容器因為資安問題，而導致 ESXi 或其它 VM 虛擬主機直接遭受攻擊。
運作 Pod 和容器的 CRX 虛擬主機，並非傳統的 VM 虛擬主機，而是 VMware 以半虛擬化技術，並且經過最佳化調校 Linux 核心，專門用於承載容器環境的虛擬主機。
管理人員可能會有疑惑，採用 CRX 虛擬主機的方式運作單個 Pod 和容器的話，那麼每台 ESXi 主機能夠承載多少台 CRX 虛擬主機？ 在 VMware 官方測試結果中，每台 CRX 虛擬主機可以在 100 毫秒內啟動 Pod 和容器，並且單台 ESXi 主機能夠運作超過 1,000 個 Pods，而整個 Supervisor Kubernetes 叢集能夠運作多達 8,000 個 Pods。
在 VMware 官方測試結果中，在 CRX 虛擬主機內的 Pod 運作 Java 容器環境，比起傳統 Pod 和容器環境傳輸量多出 30 %，而 CRX 虛擬主機和 Linux 裸機容器環境相較之下效能也提升 8 %。
對於 Supervisor Kubernetes 叢集有基本的了解之後，那麼我們開始實作演練如何在 vSphere 7 基礎架構中，建立 Supervisor Kubernetes 叢集運作環境吧。
部署 Supervisor Kubernetes 叢集
登入 vCenter Server 7 管理平台後，在 vSphere HTML 5 Client 管理介面中，依序點選「Menu > Workload Platform」，在 Getting started with Workload Platform 頁面中，捲動至最下方並點選「I'M READY」鈕。此時，系統將會彈出 Select a Cluster 視窗，請在列出的傳統 vSphere 叢集清單中，點選要轉換成新式 Supervisor Kubernetes 叢集的 vSphere 叢集。值得注意的是，vSphere 叢集必須啟動 vSphere HA 和 vSphere DRS 特色功能，才能轉換為新式 Supervisor Kubernetes 叢集，因此請在 Compatible 頁籤中，選擇適合的 vSphere 叢集後，按下 OK 鈕進入下一個 Supervisor Kubernetes 叢集組態設定流程（如圖 13 所示）。
圖 13、選擇已啟用 vSphere HA 和 DRS 的叢集，轉換為新式 Supervisor Kubernetes 叢集
在轉換叢集類型步驟 1 中，首先選擇請選擇屆時 Supervisor Kubernetes 叢集的運作規模，因為當 vSphere 叢集轉換為 Supervisor Kubernetes 叢集之後，除了部署 Kubernetes 控制平台至叢集之外，還會部署高可用性和多重 Master 運作架構的 etcd 和 Kubernetes API 堆疊，在 Supervisor Kubernetes 叢集中的每一台 ESXi 成員主機內，因此請確保屆時可用運作的 Pod 和容器數量，以及挑選相對應的 Supervisor Kubernetes 叢集規模大小。
在本文實作環境中，由於是 POC 概念驗證環境，所以選擇運作規模最小的「Tiny」Size，預估屆時將會耗損每台 ESXi 成員主機 2 CPU、8 GB 記憶體、16 GB 儲存空間等硬體資源，最多可運作 1,000 個 Pods 和容器（如圖 14 所示）。
圖 14、選擇 Supervisor Kubernetes 叢集規模大小
在轉換叢集類型步驟 2 中，管理人員必須為「控制平面」（Control Plane）組態設定網路資訊。首先，請為 Supervisor Kubernetes 叢集中每台 ESXi 成員主機，組態設定「管理網路」（Management Network）資訊，以便屆時叢集類型轉換完畢後，vCenter Server 管理平台仍然能夠管理每台 ESXi 成員主機（如圖 15 所示）。
圖 15、組態設定 Supervisor Kubernetes 叢集中每台 ESXi 成員主機管理網路資訊
接著，組態設定「名稱空間網路」（Namespace Network）資訊，選擇採用的 NSX Distributed Switch 和 Edge 叢集，並且指定採用的 DNS 伺服器 IP 位址，和屆時 Pods 運作的網段資訊，以及執行網路流量進入和流出的網段資訊（如圖 16 所示），以便屆時 Supervisor Kubernetes 叢集中每台 ESXi 成員主機和運行的 Pods，能夠透過 Kubernetes API 進行互動和溝通。
Ingress 網段，屆時將會為 Master 節點配置 VIPs（Virtual IP）以便屆時進行網路流量負載平衡，而 Egress 網段，屆時會使用 SNAT 規則將 VIPs 指派給每個名稱空間。
圖 16、組態設定 Supervisor Kubernetes 叢集中每台 ESXi 成員主機名稱空間網路資訊
在轉換叢集類型步驟 3 中，首先，我們選擇屆時套用於「Master Node」的儲存原則，接著「暫存磁碟」（Ephemeral Disks）的部份，則是選擇屆時 ESXi 成員主機運行 Pods 時使用的暫存儲存資源，最後的「印象檔快取」（Image Cache），則是由於屆時運行在 Pods 內容器所採用的容器映像檔，將會採用內部的 Harbor Container Registry，所以管理人員必須選擇容器映像檔所要使用的儲存資源（如圖 17 所示）。
請注意 !這些儲存資源皆是選擇採用「vSphere 儲存原則」，而非選擇特定的 Datastore 儲存資源。
圖 17、組態設定 Supervisor Kubernetes 叢集中每台 ESXi 成員主機所需儲存資源
在轉換叢集類型最後的步驟 4 當中，管理人員請再次檢視 Supervisor Kubernetes 叢集的各項組態設定，確認無誤後按下 FINISH 鈕，當 vSphere HTML 5 Client 管理介面下方 Recent Tasks 工作項目欄位中，組態設定 Supervisor Kubernetes 叢集的工作任務執行完畢後，在 Workload Platform 頁面中的「Clusters」頁籤內，便會出現成功轉換為 Supervisor Kubernetes 叢集的叢集相關資訊（如圖 18 所示）。
圖 18、傳統 vSphere 叢集成功轉換為 Supervisor Kubernetes 叢集
部署和管理名稱空間
請在管理介面中，依序點選「Menu > Workload Platform > Namespaces > Create Namespace」，在系統彈出建立名稱空間視窗中，請先選擇欲建立名稱空間的 Supervisor Kubernetes 叢集，然後鍵入名稱空間的名稱和描述後按下 Create 鈕即可（如圖 19 所示）。
圖 19、在 Supervisor Kubernetes 叢集中建立名稱空間
當建立名稱空間的工作任務完成後，請點選「Menu > Host and Clusters > Namespaces」項目後，管理人員即可看到剛才建立用於開發人員用途的名稱空間概要資訊。現在，我們透過整合 vSphere SSO（Single Sign-On）身份驗證機制，指派開發團隊中的名稱為「Fred」的使用者帳號具備編輯名稱空間的權限。
請在 hol 名稱空間中，依序點選「Summary > Permissions > Add Permissions」項目，在彈出的 Add Permissions 視窗中，於 Identity source 欄位選擇採用的 vSphere SSO 網域名稱，在 User/Group 欄位中，鍵入指派的 Fred 使用者帳號，最後在 Role 欄位中指派權限為「Can edit」後按下 OK 鈕即可（如圖 20 所示）。
圖 20、指派 Fred 使用者帳號具備管理 hol 名稱空間的權限
接著，在 hol 名稱空間中 Storage 區塊內按下「Add Storage」鈕，在系統彈出的 Edit Storage Poilcies 視窗中，選擇要套用到名稱空間的儲存原則，本文實作選擇「high-performance-ssd」後按下 OK 鈕即可（如圖 21 所示）。
此時，Supervisor Kubernetes 叢集將會在指定的名稱空間中，新增儲存類別和套用無限制儲存資源的預設值後，建立 Kubernetes Persistent Volumes 儲存資源。
圖 21、組態設定名稱空間所要套用的 vSphere 儲存原則
最後，管理人員可以針對 hol 名稱空間的硬體資源使用率進行限制，請依序點選「Configure > Resource Limits > Edit」項目，在彈出的 Resource Limits 視窗中，組態設定針對名稱空間的硬體資源限制設定值，例如，限制僅能使用「3 GHz」CPU 運算資源、「1 GB」Memory 運算資源、「2 GB」的儲存資源（如圖 22 所示）。
圖 22、組態設定名稱空間的硬體資源使用率，限制使用 2 GB 儲存資源