整合內建Kubernetes環境　vSphere 7登場助敏捷開發

醞釀已久的全新vSphere 7解決方案，終於在2020年3月10日由VMware官方正式發佈，同時VMware CEO Pat Gelsinger更在線上會議中表示，全新推出的vSphere 7擁抱並且內建Kubernetes。因此，管理人員無須再費心要如何建構Kubernetes叢集和高可用性環境，因為vSphere 7即可直接部署和管理Kubernetes叢集。

簡單來說，當企業組織採用vSphere 7建構虛擬化基礎架構時，便能同時打造具備VM虛擬主機和Kubernetes叢集的高可用性環境，如圖1所示，因為在vSphere 7當中已經將Kubernetes API直接原生整合至vSphere API內，幫助企業內的Dev開發人員透過Kubernetes API部署和管理容器，而Ops管理人員仍然可以採用過去管理VM虛擬主機的方式，來直接管理Kubernetes叢集和容器。

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進行管控，例如硬體資源的使用率、網路資料傳輸安全性、工作負載可用性、機敏資料存取管控等等。

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虛擬主機的影響為何，以達成更細緻更優化的資源使用率。

更彈性的硬體直通機制

在過去的vSphere基礎架構中，當ESXi主機配置支援硬體卸載機制時，可以透過DirectPath I/O硬體直通機制，如圖4所示，指派給VM虛擬主機並寫入.vmx組態設定檔案內以便獲得最佳效能。然而，啟用DirectPath I/O機制的VM虛擬主機，雖然獲得硬體最佳使用效能，但是對於VM虛擬主機的彈性則有所影響，例如無法透過vSphere DRS進行自動化調度，不能夠受到vSphere HA高可用性機制的保護。

雖然從vSphere 6.7 Update 1版本開始，支援採用vGPU技術的VM虛擬主機能夠執行vMotion遷移和快照功能，如圖5所示，但仍無法支援vSphere DRS自動化調度機制，以及vSphere HA高可用性機制。

全新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資源。

重構vSphere vMotion即時遷移機制

與前面提到的vSphere DRS調度機制一樣，為了確保vSphere vMotion即時遷移機制能夠更適合新興的應用方式，VMware官方整個重構vSphere vMotion即時遷移機制。

舉例來說，對於SAP HANA和Oracle資料庫這種大型規模的VM虛擬主機，透過傳統的vSphere vMotion即時遷移機制進行搬移，由於大型規模VM虛擬主機龐大的vCPU和記憶體空間，並且「頁面追蹤」（Page Tracing）機制是套用在所有vCPU，如圖6所示，並採用「4KB Pages」小型資料區塊傳輸vRAM虛擬記憶體空間，因此除了容易造成vMotion遷移時間過長的情況，也有可能影響應用程式的運作。

而全新的vSphere 7運作架構採用了重構後的vSphere vMotion機制，有效解決大型規模VM虛擬主機即時遷移的難題。首先，在vCPU虛擬處理器運算資源遷移的部分採用「專用」（Dedicated）的頁面追蹤機制，確保進行vMotion遷移時不會影響應用程式的運作，如圖7所示。

另外，在vRAM虛擬記憶體遷移方面，改為採用「1GB Pages」資料區塊進行傳輸並搭配其他最佳化機制，例如Memory Pre-Copy、Switchover等等。例如，在過去舊版的vSphere環境中，遷移24TB vRAM虛擬記憶體空間需要768MB Bitmap，預計遷移時間需要花費「2秒鐘」，重構後的vSphere vMotion則僅需要「175毫秒」即可完成，如圖8所示，確保大型規模VM虛擬主機切換至不同ESXi主機時，能夠由幾秒鐘的時間縮短至幾毫秒。

在VMware官方測試結果中，採用安裝Oracle資料庫的VM虛擬主機，並配置「72 vCPU和512GB vRAM」大型規模虛擬硬體資源，然後採用傳統vSphere vMotion和重構後的vSphere vMotion遷移Oracle虛擬主機，並在遷移期間透過Hammer DB進行工作負載模擬。簡單來說，重構後的vSphere vMotion除了更快速完成遷移外，在遷移期間Oracle資料庫的Commits數量相較於舊版vMotion也高出許多，如圖9所示。

支援多重因素身分驗證機制

對於提升使用者身分驗證機制安全性來說，最簡單的方式就是在良好的密碼原則之外，再搭配「多重因素身分驗證」（MultiFactor Authentication，MFA），但是目前能實作MFA多重因素身分驗證的方法太多，無法將所有MFA實作方式整合至vCenter Server。

因此，VMware針對MFA多重因素身分驗證的解決方案是，支援開放式身分驗證和授權標準，例如OAuth2、OIDC等等。在vSphere 7運作環境中，透過「識別身分同盟」（Identity Federation），如圖10所示，讓vCenter Server管理平台能夠和使用者身分驗證機制供應商進行溝通，達到簡化vSphere管理人員法規審核範圍，同時也支援更多不同的MFA多重因素身分驗證，例如熱門的ADFS（Active Directory Federation Services）。

除此之外，在vSphere 7運作環境中，還新增「vTA（vSphere Trust Authority）」信任授權機制，透過單獨管理的小型vSphere叢集建立硬體式根授權，當ESXi主機底層x86伺服器透過UEFI安全性機制啟動時，搭配「信賴平台模組」（Trusted Platform Module，TPM）進行驗證，確保x86伺服器採用正確且通過驗證程序的軟體，如圖11所示。

一旦ESXi虛擬化平台順利啟動後，便能夠運作加密VM虛擬主機，確保VM虛擬主機內的機敏資料不會外洩，並且透過REST API用於從VMCA（VMware Certificate Authority）執行憑證自動續訂的動作，簡化ESXi管理憑證的麻煩。

實作演練vSphere 7 withKubernetes

由於在撰寫本文時官方正式的vSphere ESXi 7.0和vCenter Server 7.0鏡像檔仍未釋出，但是有興趣的Ops管理人員和Dev開發人員仍然可以透過VMware HOL（Hands-on-Labs）進行vSphere 7 with Kubernetes實作演練，如圖12所示。

在開始實作演練之前，必須先了解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虛擬主機直接遭受攻擊。

管理人員可能會有疑惑，採用CRX虛擬主機的方式運作單一Pod和容器的話，那麼每台ESXi主機能夠承載多少台CRX虛擬主機？在VMware官方測試結果中，每台CRX虛擬主機可以在100毫秒內啟動Pod和容器，並且單一ESXi主機能夠運作超過1,000個Pods，而整個Supervisor Kubernetes叢集能夠運作多達8,000個Pods。

對於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所示。

在轉換叢集類型步驟1中，首先選擇屆時Supervisor Kubernetes叢集的運作規模，因為當vSphere叢集轉換為Supervisor Kubernetes叢集之後，除了部署Kubernetes控制平台至叢集之外，還會部署高可用性和多重Master運作架構的etcd和Kubernetes API堆疊，在Supervisor Kubernetes叢集中的每一台ESXi成員主機內，因此確保了屆時可用運作的Pod和容器數量，以及挑選相對應的Supervisor Kubernetes叢集規模大小。

在本次實作環境中，由於是POC概念驗證環境，所以選擇運作規模最小的「Tiny」 Size，預估屆時將會耗損每台ESXi成員主機2 CPU、8GB記憶體、16GB儲存空間等硬體資源，最多可運作1,000個Pods和容器，如圖14所示。

在轉換叢集類型步驟2中，管理人員必須為「控制平面」（Control Plane）組態設定網路資訊。首先，為Supervisor Kubernetes叢集中每一台ESXi成員主機，組態設定「管理網路」（Management Network）資訊，以便屆時叢集類型轉換完畢，vCenter Server管理平台仍然能夠管理每台ESXi成員主機，如圖15所示。

接著，組態設定「名稱空間網路」（Namespace Network）資訊，選擇採用的NSX Distributed Switch和Edge叢集，並且指定採用的DNS伺服器IP位址、屆時Pods運作的網段資訊，以及執行網路流量進入和流出的網段資訊，如圖16所示，以便到時候Supervisor Kubernetes叢集中每台ESXi成員主機和運行的Pods，能夠透過Kubernetes API進行互動和溝通。

在轉換叢集類型步驟3中，首先選擇屆時套用於「Master Node」的儲存原則，接著是「暫存磁碟」（Ephemeral Disks）部分，則選擇屆時ESXi成員主機運行Pods時使用的暫存儲存資源，最後的「鏡像檔快取」（Image Cache），因為屆時運行在Pods內容器所採用的容器映像檔，將會採用內部的Harbor Container Registry，所以必須選擇容器映像檔所要使用的儲存資源，如圖17所示。

在轉換叢集類型最後的步驟4當中，管理人員再次檢視Supervisor Kubernetes叢集的各項組態設定，確認無誤後按下〔FINISH〕按鈕，當vSphere HTML 5 Client管理介面下方Recent Tasks工作項目欄位中，組態設定Supervisor Kubernetes叢集的工作任務執行完成後，在Workload Platform頁面中的「Clusters」頁籤內，便會出現成功轉換為Supervisor Kubernetes叢集的叢集相關資訊，如圖18所示。

部署和管理名稱空間

在管理介面中，依序點選「Menu > Workload Platform > Namespaces > Create Namespace」，隨後在系統彈出建立名稱空間視窗內，先選擇欲建立名稱空間的Supervisor Kubernetes叢集，再鍵入名稱空間的名稱和描述並且按下〔Create〕按鈕，如圖19所示。

當建立名稱空間的工作任務完成之後，點選「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所示。

接著，在hol名稱空間中的Storage區塊內按下〔Add Storage〕按鈕，然後在系統彈出的Edit Storage Poilcies視窗中選擇要套用到名稱空間的儲存原則，本文實作選擇「high-performance-ssd」，最後按下〔OK〕按鈕即可，如圖21所示。

最後，管理人員可以針對hol名稱空間的硬體資源使用率進行限制，依序點選「Configure > Resource Limits > Edit」項目，然後在彈出的Resource Limits視窗中，組態設定針對名稱空間的硬體資源限制設定值，例如限制僅能使用「3GHz」CPU運算資源、「1GB」Memory運算資源、「2GB」的儲存資源，如圖22所示。

＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞