VMware日前發布Tanzu，由Project Pacific來打造全新的vSphere基礎架構平台，讓K8s API直接深度整合到vSphere API，將能夠呼應Ops管理人員以往管理VM虛擬主機的習慣，並滿足Dev開發人員在部署及管理新型態應用容器的工作負載，本文將介紹這個全新平台的特色並實際操作示範。
在2018年時，VMware併購由兩位Kubernetes（後續將簡稱為K8s）創辦人Joe Beda和Craig McLuckie創立的Heptio公司，經過幾個月的整合之後，正式在VMworld 2019年度大會上推出名為「VMware Tanzu」的解決方案。
過去IT管理人員對於VMware解決方案的認知，是建構在vSphere ESXi虛擬化平台中，相關服務皆圍繞著VM虛擬主機為中心。然而，現代化的應用程式和服務已經改採「容器」（Container），搭配容器調度管理平台K8s為主，搭配運作在VM虛擬主機內傳統的應用程式，如圖1所示。在Tanzu解決方案中，最亮眼的運作元件之一應屬「Project Pacific」。簡單來說，Project Pacific便是將vSphere ESXi虛擬化平台，與K8s容器調度平台深度融合在一起，如圖2所示，並針對企業和組織提供下列優點：
圖1 傳統應用服務和現代化分佈式應用服務示意圖。（圖片來源：VMware官網 – Introducing Project Pacific）
圖2 Project Pacific新一代vSphere管理平台運作架構示意圖。（圖片來源：VMware vSphere Blog - Introducing Project Pacific）
‧vSphere原生支援K8s：在Project Pacific中，將K8s直接嵌入至vSphere的控制平面中，讓管理人員可以統一管理VM虛擬主機和容器的各項資源，例如運算、儲存、網路等等，並且管理人員無須更換管理工具和操作習慣，透過原有的vSphere HTML 5 Client管理工具，即可查看和管理K8s物件，例如Pod、Namespace、Container等等。
‧應用程式為管理中心：過去管理中心以VM虛擬主機為主，現在管理人員可以直接透過vCenter Server管理平台，針對K8s叢集直接管理所有的容器和VM虛擬主機及企業進階功能，包含vSphere HA、vSphere DRS、vSphere vMotion等等，讓企業營運服務中的應用程式正式成為管理中心。
‧加速DevOps步調：在現有的IT管理工具中，Ops管理人員負責建構和管理K8s叢集，而Dev開發人員則使用K8s API存取SDDC軟體定義基礎架構。現在Dev和Ops可以透過vSphere看到相同的運作環境並進行管理和部署作業，加速協同運作。
以下將針對在VMworld 2019年度大會上發佈的VMware Tanzu管理平台中，由Project Pacific打造的全新下一代vSphere基礎架構平台，也就是將K8s API直接深度整合到vSphere API當中，讓企業組織內的Dev開發人員可以透過K8s API管理容器，而Ops管理人員能夠像過去管理vSphere ESXi中VM虛擬主機的方式，來直接管理K8s叢集和容器。
深入剖析Project Pacific特色
Project Pacific所具備的特色功能，可分成以下三方面來加以說明。
K8s即平台（K8s as a Platform）
過去無論是開發人員或管理人員對於K8s調度管理平台的印象，可能僅能針對「容器」（Container）進行負載平衡和管理的動作。
而Project Pacific則是將K8s打造成可以調度「任何工作負載」的管理平台，並且直接原生融入至原有的vSphere虛擬化基礎運作架構中。
現在開發人員可以採用YAML檔案，透過K8s API管理和調度容器的生命週期，而IT管理人員也可採用YAML檔案，透過vSphere API管理和調度VM虛擬主機的生命週期，如圖3所示。因此，企業組織能夠採用相同的標準作業流程，來管理企業營運服務的生命週期，同時加速整體數位轉型的步調。
圖3 透過K8s API和vSphere API同時管理容器和VM虛擬主機運作架構示意圖。（圖片來源：VMware vSphere Blog - Project Pacific - Technical Overview）
以應用程式為中心
在舊有的vSphere虛擬化基礎架構中，Ops管理人員所著重的是「VM虛擬主機」，舉例來說，當運作VM虛擬主機底層x86硬體伺服器需要進行計畫性維運時，可以透過vSphere vMotion線上遷移機制，讓VM虛擬主機和內部運作的營運服務能夠不中斷地遷移且持續運作，即便發生非計畫性故障事件時，也可透過vSphere HA或FT高可用性機制，讓VM虛擬主機僅發生短暫的停機時間或無縫接手服務，甚至當VM虛擬主機工作負載異常暴增時，也可以針對VM虛擬主機使用的硬體資源進行限制的動作等等。
現在可透過K8s運作架構中大家所熟知的「Namespace」機制，來解決無法以應用程式為中心的困擾。簡單來說，管理人員可以將Namespace想像成一個資料夾，它可以承載各式各項的資源，例如容器、VM虛擬主機、vDisk儲存資源、加密機制、HA高可用性機制等等。
如圖4所示，在一個Namespace當中同時運作著傳統應用程式的VM虛擬主機，以及不適合容器化由VM虛擬主機組成的資料庫叢集，搭配適合容器運作架構的現代化應用程式，以及無伺服器架構的Serverless服務，而管理人員能夠輕鬆地針對整個Namespace進行管控，例如硬體資源的使用率、網路資料傳輸安全性、工作負載可用性、機敏資料存取管控等等。
圖4 以Namespace為單位進行工作負載管控作業示意圖。（圖片來源：VMware vSphere Blog - Project Pacific - Technical Overview）
Supervisor - 新世代叢集架構
對管理人員來說，過去在vSphere基礎運作架構中，便是透過ESXi的「Hypervisor」機制，將底層x86伺服器硬體資源抽象化之後，提供給上層運作的VM虛擬主機使用，並且透過建立vSphere叢集，將底層硬體資源進行匯整。
而目前在Project Pacific運作架構中，將採用新世代叢集運作架構「Supervisor Cluster」。簡單來說，在傳統的K8s叢集中，節點主機無論是實體伺服器或VM虛擬主機皆採用Linux主機，並且管理人員透過「Kubelet」進行管理的動作，而新世代叢集Supervisor Cluster的節點主機則是ESXi，並且原生整合至ESXi之後以「Spherelet」進行管理的動作。
在Supervisor Cluster上運作的Pod都會在各自「獨立」的VM虛擬主機內運作，這並非傳統的VM虛擬主機，而是經過最佳化調校並包括Linux核心，最適合容器環境運作的半虛擬化VM虛擬主機稱之為「CRX」，如圖5所示。因此，最佳化後的CRX虛擬主機能夠在「100毫秒（ms）」之內啟動Pod，並在單台ESXi主機上可以運作超過1,000個Pods，整個Supervisor Cluster最多可運作多達8,000個Pods，同時根據VMware官方內部測試結果顯示，在CRX虛擬主機Pod內運作的Java比傳統Pod傳輸量高出30%，相較於裸機的Linux主機也快8%。
圖5 針對容器工作負載最佳化的CRX虛擬主機運作示意圖。（圖片來源：VMware vSphere Blog - Project Pacific - Technical Overview）
此外，當企業需要在Supervisor Cluster中建構Guest Cluster時，如圖6所示，也就是在Linux VM虛擬主機中建構傳統K8s Cluster時，也能夠透過Cluster API與上層Supervisor Cluster進行互動來達到管理一致性的目的。
圖6 Supervisor Cluster上層運作的Guest Cluster透過Cluster API進行互動的架構示意圖。（圖片來源：VMware vSphere Blog - Project Pacific - Technical Overview）
實作演練Project Pacific運作
雖然目前Project Pacific仍處於技術預覽階段，但管理和開發人員仍然可以透過VMware HOL（Hands-on-Labs）實作。 接下來，將實作演練如何建構Supervisor Cluster，並且部署多個Nginx容器和網路負載平衡機制。
Ops管理人員建構Supervisor Cluster
先登入vCenter Server的vSphere HTML 5 Client管理介面，依序點選「Menu > Workload Platform」。
然後，在Getting started with Workload Platform頁面最下方按下〔I'm Ready〕按鈕，表示管理人員同意在目前的vSphere Cluster中啟用並轉換為新世代Supervisor Cluster運作架構。
這個時候，系統將會彈出Select a Cluster視窗，選擇要轉換成Supervisor Cluster運作架構的vSphere Cluster後，如圖7所示，按下〔OK〕按鈕進入下一個組態設定。
圖7 選擇要轉換成新世代Supervisor Cluster運作架構的vSphere Cluster。
接著，必須組態設定轉換後的Supervisor Cluster，管理人員可以依據工作負載的情況，選擇適合的叢集大小，本文實作環境選擇「Tiny」規模大小，可運作約1,000 Pods，如圖8所示。
圖8 選擇Supervisor Cluster運作規模大小。
在Network組態設定頁面中，管理人員必須為「控制平面」（Control Plane）組態設定網路資訊。首先，必須為Supervisor Cluster架構中的每台ESXi成員主機，組態設定「管理網路」（Management Network）資訊，以便屆時vCenter Server管理平台能夠管控每台ESXi成員主機。
然後，組態設定「名稱空間網路」（Namespace Network）資訊，如圖9所示，以便屆時Supervisor Cluster架構中的每台ESXi成員主機和Pods，能夠透過K8s API進行互動和溝通，在本文實作環境中採用NSX Distributed Switch和Edge，並且主要節點將會配置VIPs（Virtual IP），以便屆時進行網路流量負載平衡。
圖9 組態設定Supervisor Cluster中管理網路和名稱空間網路資訊。
在Storage組態設定頁面中，由於屆時運作容器的容器映像檔，會由整合至內部的Harbor Container Registry提供，而非讓ESXi節點主機至網際網路上公開的Container Registry下載容器映像檔，所以管理人員必須選擇容器映像檔所要使用的儲存資源。而在Review and Confirm頁面中，管理人員再次檢視Supervisor Cluster的組態設定內容是否正確，確認無誤後按下〔Finish〕按鈕，如圖10所示，當下方Recent Tasks工作項目欄位中，組態設定Supervisor Cluster的工作任務執行完畢，在Workload Platform頁面中的〔Clusters〕頁籤內，便會出現已經轉換成Supervisor Cluster的vSphere Cluster。
圖10 再次檢視Supervisor Cluster運作環境組態設定是否正確。
此時，回到Hosts and Clusters頁面中，將會看到系統自動建立一個名稱為「Namespaces」的「資源集區」（Resource Pool），點選並進入資源集區當中，將會發現系統已經自動啟動和運作一台VM虛擬主機，這台便是擔任Kubernetes MasterAPI工作任務的VM虛擬主機，如圖11所示。
圖11 成功部署Supervisor Cluster並啟動Kubernetes MasterAPI VM虛擬主機。
至此，已經成功部署Supervisor Cluster，接著將在Supervisor Cluster內建立一個新的名稱空間，這個名稱空間便是K8s的核心運作元件，也就是開發人員所熟悉和使用的名稱空間。在vSphere HTML 5 Client管理介面中，依序點選「Menu > Workload Platform > Namespaces > Create Namespace」項目，在彈出的Create Namespace視窗內，選擇準備建立名稱空間的vSphere資料中心和叢集，然後在Name欄位內鍵入所要新增的名稱空間（本文實作環境為hol），最後按下〔Create〕按鈕即可。
當新增名稱空間的工作任務完成後，依序點選「Host and Clusters > Namespaces > hol」項目後，便可以看到新增用於開發人員用途的K8s名稱空間概要資訊，如圖12所示。
圖12 新增用於開發人員用途的K8s名稱空間概要資訊。
現在將針對剛才所新增的「hol」K8s名稱空間，指派開發團隊中的「Fred」使用者帳號具備編輯權限，而在使用者帳號身分驗證的部分，則採用原有的vSphere SSO（Single Sign-On）身分驗證機制。
在hol K8s名稱空間中，依序點選「Summary > Permissions > Add Permissions」項目，在彈出的Add Permissions視窗中依照運作環境需求進行設定。首先，在Identity source中選擇採用的vSphere SSO網域名稱，在User/Group欄位中鍵入欲指派的使用者帳號或群組（本文實作為Fred），最後在Role欄位中指派權限（本文實作為Can edit）即可。目前，在hol K8s名稱空間中，僅「Fred」這個使用者帳號能夠進行存取和編輯，其他使用者帳號和群組皆無法存取。
因此，管理人員透過建立「儲存原則」（Storage Policy），然後與K8s名稱空間進行關聯，便可以達到K8s名稱空間使用不同的儲存資源或限制儲存資源使用率的目的。
接著，在hol K8s名稱空間中，依序點選「Summary > Storage > Add Storage」項目，在彈出的Edit Storage Poilcies視窗中，選擇所要套用的儲存原則（本文實作為high-performance-ssd），然後按下〔OK〕按鈕，便可以看到high-performance-ssd儲存原則已經與hol K8s名稱空間進行關聯，如圖13所示。此時系統將會在指定的K8s名稱空間儲存資源中，建立K8s儲存用途的Persistent Volumes。
圖13 指派使用者帳號和群組針對hol K8s名稱空間的存取權限，並與指定的儲存原則進行關聯。
管理人員也可針對hol K8s名稱空間的硬體資源使用率進行限制，依序點選「Configure > Resource Limits > Edit」項目，在彈出的Resource Limits視窗內，針對hol K8s名稱空間的硬體資源進行限制，例如限制僅能使用3,000MHz和1,000MB的CPU和Memory運算資源，在儲存資源的部分僅能使用2,000MB，如圖14所示。
圖14 組態設定限制hol K8s名稱空間的硬體資源使用率。
Supervisor Cluster部署和管理容器
當vSphere系統管理人員建構完成Supervisor Cluster之後，可以開始專注在開發人員的使用層面上，開始使用vSphere K8s Cluster進行部署和管理容器的動作。
首先，將為開發人員的Windows或Linux或Mac開發主機安裝K8s CLI指令工具。在vSphere HTML 5 Client管理介面中，依序點選「Namespaces > hol > Summary > Status > Link to CLI Tools > Open」，然後選擇安裝的作業系統類型，即可從vCenter Server下載K8s CLI指令工具。
在本文實作環境中，將在Ubuntu虛擬主機中，透過wget指令進行下載，然後搭配unzip指令進行解壓縮的動作，如圖15所示。
圖15 在Ubuntu虛擬主機中下載和解壓縮K8s CLI指令工具。
現在開發人員可以透過K8s CLI指令工具連線至Supervisor Cluster控制平面，也就是vCenter Server，鍵入「kubectl vsphere login」指令，並指定vCenter Server IP位址「--server=192.168.124.1」，以及登入的使用者帳號「--vsphere-username fred@vsphere.local」。
成功通過身分驗證程序後，執行「kubectl config get-contexts」指令，查詢開發人員帳號Fred能夠存取的名稱空間有哪些。再執行「kubectl config use-context hol」指令，將使用的名稱空間指向至「hol」。最後執行「kubectl get all」指令，查詢hol名稱空間內運作的工作負載，由於hol名稱空間內尚未運作任何容器，所以會顯示為「No resources found」，如圖16所示。
圖16 開發人員透過kubectl指令與Supervisor Cluster控制平面建立連線。
由於在建立Supervisor Cluster時已經指派和關聯儲存資源，現在便可以透過YAML檔案，執行建立K8s Persistent Volume的動作。首先，查看「nginx-claim.yaml」檔案內容，然後執行「kubectl apply -f nginx-claim.yaml」指令建立，再執行「kubectl get pvc」確認Persistent Volume是否建立完成，如圖17所示。
圖17 建立K8s Persistent Volume儲存資源。
至此，就能夠執行部署Pod和容器的動作。首先，執行「cat nginx-pers.yaml」指令，查看部署Pod和容器的YAML檔案內容，確認無誤後，輸入「kubectl apply -f nginx-pers.yaml」指令，執行部署Pod和Nginx容器的動作。然後，執行「kubectl get all」指令以確認Pod和Nginx容器是否部署成功，如圖18所示。
圖18 執行和確認Pod和Nginx容器是否部署成功。
開發人員可以使用相同的容器管理經驗，執行「kubectl exec -it」指令，配合Nginx容器名稱，即可進入容器內部進行互動操作，如圖19所示。此時，回到vSphere HTML 5 Client管理介面，再次確認Pod和Nginx容器是否都已經部署成功，並且觀察是否使用Persistent Volume儲存資源。
圖19 進入容器內部進行互動操作。
在管理介面中，依序點選「Menu > Hosts and Clusters > Namespaces > hol」項目，就會看到一台以「nginx」開頭為命名的特殊VM虛擬主機圖示，裡頭便運作剛才所部署的Pod和Nginx容器。
點選該台VM虛擬主機後，再點選〔Monitor〕頁籤便可以看到有關於這個Pod和容器的K8s Events，接著點選「Storage > Persistet Volume > Volume Name > Details > Basic」項目，即可看到哪一台CRX虛擬主機，使用哪個Datastore和Persistent Volume儲存資源，並且與哪一個儲存原則互相關聯，如圖20所示。
圖20 查詢部署的Nginx容器使用的儲存資源詳細資訊。
最後，部署具備流量負載平衡機制的Nginx網頁伺服器運作環境。首先，透過YAML檔案內的「replicas : 3」表示即將部署3個Nginx容器。先執行「kubectl apply -f nginx-lbsvc.yaml」進行部署動作，再輸入「kubectl get all」命令確認已經部署3個Nginx容器，如圖21所示。
圖21 部署3個Nginx容器，並準備建立網路流量負載平衡機制。
執行「kubectl get svc -o wide」，確認是否部署K8s負載平衡機制，稍待一小段時間後，即可看到「External-IP」欄位出現負載平衡IP位址，如圖22所示。
圖22 確認Kubernetes負載平衡機制是否部署成功。
此時，便可以開啟瀏覽器分頁，並在URL鍵入剛才得到的負載平衡IP位址。但是，可能會無法存取Nginx頁面資訊，主要原因在於，預設情況下，K8s Namespace Ingress會「Block」所有網路流量所導致。
可以查看一下enable-policy.yaml檔案內容為「allow-all」，執行「kubectl apply -f enable-policy.yaml」來允許K8s Namespace Ingress網路流量通過，如圖23所示。
圖23 允許K8s Namespace Ingress網路流量通過。
事實上，當開發人員允許K8s Namespace Ingress網路流量通過時，系統就會在NSX Distributed Firewall防火牆規則中，自動「新增」Namespace Ingress網路流量允許規則，如圖24所示。此時，再次回到瀏覽器分頁並且在URL欄位鍵入Nginx容器的負載平衡IP位址，就能夠正確存取Nginx首頁了。
圖24 系統自動新增Namespace Ingress網路流量允許規則。
結語
透過本文的深入剖析和實作演練後，將會發現新一代的vSphere管理平台Project Pacific，能夠提供Ops管理人員過往管理VM虛擬主機的習慣，也同時滿足Dev開發人員在部署和管理新型態應用容器的工作負載，幫助企業和組織加速前往DevOps的步調。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞