在先前的技術專欄中，已經實作適用於研發和測試環境，建構基於 Kubernetes 叢集技術的 VMware Tanzu 容器平台。然而，在預設情況下，部署 TCE 託管叢集引導程序中，無論選擇採用預設的「Kube-vip」，或需要事先建置且購買軟體授權的「NSX Advanced Load Balancer」負載平衡機制，都僅適用於 TCE 管理叢集，而非實際運作容器的 TCE 工作負載叢集，這對於實際需要存取容器服務的使用者來說，無疑是一大困擾。

因此，在本文中將說明和實戰演練，部署適用於營運環境的 TCE 託管叢集架構，並且整合 CNCF（Cloud Native Computing Foundation） 中，於 Orchestration & Management 類別中 Service Proxy 項目內，知名的 MetalLB 網路負載平衡機制，確保部署應用服務容器至 TCE 工作負載叢集時，能夠透過 MetalLB 負載平衡機制，在應用服務容器之前處理各式請求流量（如圖 1 所示），然後正確將請求流量重新導向至 TCE 工作負載叢集內運作的容器服務。

MetalLB 負載平衡機制，可以輕鬆整合至 Kubernetes 叢集運作架構中，並且使用標準的路由通訊協定，例如，Layer 2 Mode（ARP 和 NDP）、BGP，以便外部使用者能夠順利感知 Kubernetes 叢集中，由 MetalLB 提供的負載平衡 IP 位址，進而導向至 Kubernetes 叢集中的容器服務。

當 MetalLB 採用 Layer 2 部署模式時，倘若網路環境為「IPv4」時則採用 ARP 通訊協定，倘若為「IPv6」網路環境時則採用 NDP 通訊協定，以便外部存取者能夠順利路由至內部容器服務中。當採用 BGP 部署模式時，Kubernetes 叢集中所有節點主機都會建立 BGP 機制，以便和網路環境中所有的路由器建立 Peering Sessions，達到跨多個網路節點的負載平衡機制，並且可以進行更精細的網路流量管控（如圖 2 所示）。

在實戰演練小節中，將帶領管理人員一步一步，把最新版本的 TCE 容器平台部署在 VMware vSphere 7 虛擬化環境中，然後整合輕巧易用功能強大的 MetalLB 負載平衡機制，為屆時運作的眾多容器服務完成網路流量負載平衡的目的。

首先，透過「tanzu cluster」指令，部署「引導叢集」（Bootstrap Cluster），然後部署用於正式營運環境的「託管叢集」（Managed Cluster）架構，當引導叢集建立管理叢集後，便會開始將所有管理物件移動至「管理叢集」（Management Cluster）（如圖 3 所示）。

在部署 TCE 託管叢集架構之前，必須額外準備好一台機器擔任 Tanzu CLI 管理主機，以便稍後執行 TCE 託管叢集的初始化部署流程。管理人員可以依據管理喜好，將 Tanzu CLI 指令工具集安裝在 Linux / Mac / Windows 環境中，本文實作環境為 Windows 主機安裝 Tanzu CLI 指令工具集。值得注意的是，Tanzu CLI 管理主機的記憶體，至少要大於「6 GB」以上，否則屆時相關引導容器將會出現資源不足而發生部署失敗的情況，或遭遇到非預期的錯誤。

在 Windows 運作環境中，必須先安裝 PowerShell 中的 Chocolatey 套件安裝管理工具，接著完成「kubectl、Docker Desktop、WSL2」運作環境後，便能順利安裝 Tanzu CLI 指令工具。倘若，這台 Tanzu CLI 管理主機無法接觸網際網路的話，請先至 TCE GitHub 專案頁面手動下載後進行離線安裝。

確認 Chocolatey 套件安裝管理工具，執行下列 PowerShell 指令，即可達成安裝 kubectl、Docker Desktop、Tanzu CLI 的目的（如圖 5 所示），管理人員可以加上「--version」參數，指定希望安裝的版本，舉例來說，本文實作環境中倘若未加上指定版本參數時，預設將會安裝前一版 v0.11 版本，但 TCE 已經於日期發佈最新的 v0.12 版本，此時便可以加上參數安裝指定版本。

值得注意的是，倘若採用手動下載離線安裝的方式時，必須在安裝好 Tanzu CLI 指令工具後，手動將「C:\Program Files\tanzu」路徑，加入至 Windows 主機環境變數當中。

部署 TCE 託管叢集時，Tanzu CLI 主機會需要與 vCenter 管理平台進行通訊，此時會使用 SSH-2 RSA 4096-bit 的 SSH 加密金鑰進行通訊作業，所以先在 Tanzu CLI 主機上，執行「ssh-keygen -t rsa -b 4096」指令產生 SSH 加密金鑰對，以便稍後部署時使用。值得注意的是，預設情況下產生的 SSH 加密金鑰對中，「id_rsa」檔案為 SSH 加密金鑰中的「私有金鑰」（Private Key），而「id_rsa.pub」則是「公開金鑰」（Public Key），稍後與 vCenter 管理平台通訊時將會需要公開金鑰內容。

執行「ssh-agent 和 ssh-add」指令，將剛才產生 SSH 加密金鑰對中的私有金鑰內容，儲存至 Windows 安全性內容中，系統會將其和目前登入的 Windows 使用者帳號進行關聯，稍後部署 TCE 託管叢集需要進行通訊驗證作業時，啟動的 ssh-agent 系統服務會自動擷取剛才匯入的私有金鑰內容，並自動傳送給 SSH 用戶端進行驗證（如圖 6 所示）。

首先，請確保採用「vSphere 6.7 U3 或 vSphere 7」版本的 vSphere 虛擬化環境，才能順利支援並部署 TCE 託管叢集，接著前往 VMware Customer Connect 網站，下載由 VMware 官方打包好運作環境的 OVA 檔案。

目前，VMware 官方支援採用 Photon OS v3 和 Ubuntu 2004 系統建構的容器平台，屆時便是負責運作和承載 TCE 管理叢集和工作負載叢集，本文實作環境採用最新發佈 TCE v0.12 版本，搭配最新發佈「Photon v3 Kubernetes v1.22.8」的 OVA 版本。當然，管理人員也可以依據運作環境需求，選擇維運人員偏好的 Kubernetes 版本。

順利下載 OVA 檔案後，請在 vCenter 管理介面中，依序點選「Datacenter > Actions > Deploy OVF Template」項目，在 Deploy OVF Template 視窗中，請依序點選「Local file > UPLOAD FILES」選項，然後選擇剛才下載完成的 OVA 檔案。

在 Select a name and folder 頁面中，請設定匯入的 VM 虛擬主機名稱，本文實作採用預設的「photon-3-kube-v1.22.8」名稱，並部署在 Datacenter 中的「TCE」資料夾內，在 Select a compute resource 頁面中，選擇本文實作環境中用於 TCE 工作負載的「K8s-Cluster」，在 Review details 頁面中，確認部署資訊無誤後按下 Next 鈕繼續部署程序。

在 Select Storage 頁面中，選擇採用的 Datastore 儲存資源，並指定使用 Thin Provision 或 Thick Provision 虛擬硬碟格式，在 Select networks 頁面中，選擇本文實作環境中用於 TCE 工作負載的「TCE-Network」虛擬網路。最後，在 Ready to complete 頁面中，再次確認所有部署資訊，確認無誤後按下 Finish 鈕，便開始進行部署作業。此時，從 vCenter 管理介面下方 Recent Tasks 工作列中，可以看到二項工作任務「Import OVF package」和「Deploy OVF template」執行中。

值得注意的是，這是用於部署 TCE 託管叢集和工作負載叢集的基礎映像檔，所以必須將匯入後的 VM 虛擬主機格式，轉換為「VM 範本」（VM Template）格式才行。請在匯入 OVF 的工作任務完成後，點選名稱為「photon-3-kube-v1.22.8」的虛擬主機後，依序點選「Actions > Template > Convert to Template > Yes」，確認該台 VM 虛擬主機已經轉換為 VM 範本格式，並存放在 TCE 資料夾中（如圖 7 所示）。

請切換至 Tanzu CLI 管理主機，執行「tanzu management-cluster create --ui」指令，系統將會啟動 kickstart UI 進行 TCE 託管叢集初始化部署流程。簡單來說，整個部署流程大約分為二個步驟，第一步是部署 TCE 管理叢集，接著則是部署 TCE 工作負載叢集（如圖 8 所示）。

在 Management Cluster Settings 頁面中，管理人員將指定屆時 TCE 託管叢集的運作規模。在 Development 和 Production 選項中，兩者最主要的差別在於，稍後部署的 TCE 託管叢集的「控制平面節點」（Control Plane Node）數量，選擇 Development 只會建立「1 台」控制平面節點，而選擇 Production 選項則會一次建立「3 台」控制平面節點。在本文實作環境中，選擇 Development 選項中控制平面節點規模為「Large（CPU : 4，RAM : 16GB，Disk : 40GB）」。

在 Management Cluster Name 欄位中，請鍵入在部署 TCE 託管叢集所要採用的名稱，本文實作為「tce-cluster」，在 Control Plane Endpoint Provider 下拉選單中，管理人員可以選擇採用預設的「Kube-vip」或「NSX Advanced Load Balancer」，在 Control Plane Endpoint 欄位，請鍵入屆時 TCE 託管叢集中控制平面節點的 VIP 位址，本文實作為「10.10.75.50」，在 Worker Node Instance Type 下拉選單中，選擇工作負載叢集的規模為「Small（CPU : 2，RAM : 4GB，Disk : 20GB）」，最後本文實作為測試環境用途所以不勾選「Enable Audit Logging」選項（如圖 10 所示）。

完成 TCE 管理叢集的部署作業後，接著部署 TCE 工作負載叢集。簡單來說，我們可以直接複製剛才用於部署 TCE 管理叢集的 YAML 檔案後，進行組態內容的修改後即可部署 TCE 工作負載叢集。首先，切換到儲存 TCE 管理叢集的 YAML 檔案路徑「C:\Users\Weithenn\.config\tanzu\tkg\clusterconfigs」，將剛才部署產生的 TCE 管理叢集的 YAML 檔案複製為「workload01.yaml」。

原則上，只需要依據運作環境需求修改相關欄位的內容即可，本次實作環境修改 2 個欄位內容，首先是指定 TCE 工作負載叢集名稱的「CLUSTER_NAME」，工作負載叢集名稱不得超過「42 個字元」，並且必須符合 RFC1123 的要求，倘若未指定的話系統屆時將會產生隨機名稱。

接著是指定 TCE 工作負載叢集中控制平面 IP 位址的「VSPHERE_CONTROL_PLANE_ENDPOINT」，這個 IP 位址就是屆時工作負載叢集的 API Server，管理人員必須確保這個 IP 位址，在 DHCP 伺服器配發的 IP 位址範圍之外。本文實作環境，組態設定 TCE 工作負載叢集名稱為「workload01」，而 API Server 的 IP 位址為「10.10.75.60」。

執行「tanzu cluster create workload01 --file workload01.yaml」指令，開始部署 TCE 工作負載叢集，大約 10 分鐘左右即可部署完成，同樣的管理人員會發現 TCE 工作負載叢集，也會建立控制平台和工作負載節點主機，當部署作業完成後鍵入「tanzu cluster list」指令，確認指定的 workload01 工作負載叢集是否成功部署完成（如圖 15 所示）。

在部署 MetalLB 負載平衡機制之前，請同樣先執行「tanzu management-cluster kubeconfig get workload01 --admin」指令，儲存驗證程序憑證，執行「kubectl config use-context workload01-admin@workload01」指令，確保由原本連線的 TCE 管理叢集，切換至剛建立的 TCE 工作負載叢集，執行「kubectl get nodes」指令，和 TCE 工作負載叢集 API 服務進行互動，執行「kubectl get pods –all-namespaces」指令，確認 TCE 工作負載叢集中所有的 Pods 的運作狀態。

準備就緒後，執行「kubectl apply -f」指令，搭配 MetalLB 負載平衡的「namespace.yaml」和「metallb.yaml」設定檔，部署名稱為「metallb-system」的名稱空間至工作負載叢集中，然後再整合預先編輯好的「metallb-config.yaml」組態設定檔，指定 MetalLB 負載平衡機制使用 IP 位址範圍，本文實作指定 5 個 IP 位址由「10.10.75.61 – 10.10.75.65」，接著執行「kubectl apply -n metallb-system -f metallb-config.yaml」指令，組態設定 MetalLB 負載平衡機制 IP 位址使用範圍，執行「kubectl -n metallb-system get pods」指令，檢查 MetalLB 負載平衡機制中 Controller 和 Speaker 容器是否部署完成並順利運作（如圖 17 所示）。

首先，執行「kubectl create ns yelb」指令，部署 Yelb 應用服務使用的名稱空間，執行「kubectl -n yelb apply」指令部署 Yelb 應用服務和相關容器，執行「kubectl -n yelb get pods」指令，確保 Yelb 應用服務中運作元件容器皆已經啟動完成。

此時，執行「kubectl -n yelb get svc」指令，確保 MetalLB 負載平衡機制，是否將其中一個負載平衡 IP 位址，指派給 Yelb 應用服務使用，在本文實作環境中從「EXTERNAL-IP」欄位，可以看到已經指派「10.10.75.61」負載平衡 IP 位址，給予 Yelb 應用服務使用（如圖 19 所示）。