網管人雜誌
本文刊載於
網管人雜誌第 170 期 - 2020 年 3 月 1 日出刊，
NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。
前言深入剖析 Project Pacific 特色功能 K8s 即平台（K8s as a Platform） 以應用程式為中心 Supervisor - 新世代叢集架構實作演練 Project Pacific 運作環境 Ops 管理人員 - 建構 Supervisor Cluster Supervisor Cluster 部署和管理容器結語前言
在 2018 年時，VMware 併購由二位 Kubernetes（後續將簡稱為 K8s）創辦人 Joe Beda 和 Craig McLuckie 的
Heptio 公司，經過幾個月的整合之後，正式在
VMworld 2019 年度大會上推出名為「
VMware Tanzu」的解決方案。
「Tanzu」這個產品名稱的由來有二個意義，第一個意義是日語當中表示可移動式的模組化櫥櫃，第二個意義則是斯瓦裡語當中表示樹支不斷分叉。
過去，IT 管理人員對於 VMware 解決方案的認知，便是建構在 vSphere ESXi 虛擬化平台中，相關服務皆圍繞著 VM 虛擬主機為中心，然而現代化的應用程式和服務已經改採
「容器」（Container），搭配容器調度管理平台 K8s 為主，搭配運作在 VM 虛擬主機內傳統的應用程式（如圖 1 所示）。
圖 1、傳統應用服務和現代化分佈式應用服務示意圖
在 Tanzu 解決方案中，最亮眼的運作元件之一應屬「
Project Pacific」。簡單來說，Project Pacific 便是將 vSphere ESXi 虛擬化平台，與 K8s 容器調度平台深度融合在一起（如圖 2 所示），並針對企業和組織提供下列優點：
- 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 看到相同的運作環境並進行管理和部署作業加速協同運作。
圖 2、Project Pacific 新一代 vSphere 管理平台運作架構示意圖
本文，將針對在 VMworld 2019 年度大會上發佈的 VMware Tanzu 管理平台中，由 Project Pacific 打造的全新下一代 vSphere 基礎架構平台，也就是將 K8s API 直接深度整合到 vSphere API 當中，讓企業和組織內的 Dev 開發人員可以透過 K8s API 管理容器，而 Ops 管理人員可以像過去管理 vSphere ESXi 中 VM 虛擬主機的方式，直接管理 K8s 叢集和容器。
深入剖析 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 虛擬主機運作架構示意圖
以應用程式為中心
在過去 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 為單位進行工作負載管控作業示意圖
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% 。
為了更方便運作容器，在 Project Pacific 中也將「Harbor」Container Registry 整合至 vSphere，只要透過 vCenter Server 管理平台，即可管理 Harbor Container Registry 。
圖 5、針對容器工作負載最佳化的 CRX 虛擬主機運作示意圖
此外，當企業或組織需要在 Supervisor Cluster 中建構 Guest Cluster 時（如圖 6 所示），也就是在 Linux VM 虛擬主機中建構傳統 K8s Cluster 時，也可以透過 Cluster API 與上層 Supervisor Cluster 進行互動達到管理一致性的目的。
圖 6、Supervisor Cluster 上層運作的 Guest Cluster 透過 Cluster API 進行互動的架構示意圖
實作演練 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 鈕後進入下一個組態設定流程。
請注意，準備轉換為 Supervisor Cluster 的 vSphere Cluster，必須已經啟用 HA 和 DRS進階特色功能才行。
圖 7、選擇要轉換成新世代 Supervisor Cluster 運作架構的 vSphere Cluster
接著，我們必須組態設定轉換後的
Supervisor Cluster，管理人員可以依據工作負載的情況，選擇適合的叢集大小，本文實作環境選擇「
Tiny」規模大小，可運作約
1,000 Pods（如圖 8 所示）。
屆時，將會在 Supervisor Cluster 每台 ESXi 成員主機中，部署高可用性的 etcd 和 Kubernetes API。
圖 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」這個使用者帳號能夠進行存取和編輯，其它使用者帳號和群組皆無法存取（如圖 13 所示）。
因此，管理人員可以透過建立「儲存原則」（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 。
請注意，預設的情況下，系統並不會限制 K8s 名稱空間儲存資源的使用率，所以可以看到關聯的儲存原則旁有「No limit」字樣。
圖 13、指派使用者帳號和群組針對 hol K8s 名稱空間的存取權限，並與指定的儲存原則進行關聯
最後，管理人員可以針對 hol K8s 名稱空間的硬體資源使用率進行限制，請依序點選「
Configure > Resource Limits > Edit」項目，在彈出的 Resource Limits 視窗中，管理人員可以針對 hol K8s 名稱空間的硬體資源進行限制，例如，限制僅能使用「
3000 MHz 和 1000 MB」的 CPU 和 Memory 運算資源，在儲存資源的部份僅能使用「
2000 MB」（如圖 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 所示）。
下載的 K8s CLI 指令工具中，將包含 kubectl 和 vSphere Plug-in。
圖 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 Resource 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 所示）。
圖 19、進入容器內部進行互動操作
現在，我們可以回到 vSphere HTML 5 Client 管理介面，再次確認 Pod 和 Nginx 容器是否部署成功，並且是否使用 Persistent Volume 儲存資源。請在管理介面中，依序點選「
Menu > Hosts and Clusters > Namespaces > hol」項目，即可看到一台以「
nginx」開頭為命名的特殊 VM 虛擬主機圖示，裡頭便運作剛才所部署的 Pod 和 Nginx 容器。
這台特殊的 VM 虛擬主機，便是先前所提到針對容器工作負載最佳化的 CRX虛擬主機。因此，圖示也和一般 vSphere VM 虛擬主機不同。
點選該台 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 的步調。
