網管人雜誌
本文刊載於 網管人雜誌第 198 期 - 2022 年 7 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。本文目錄
前言
在先前的技術專欄中，已經實作適用於研發和測試環境，建構基於 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 工作負載叢集內運作的容器服務。
圖 1、TCE 容器平台部署和應用服務負載平衡架構運作示意圖
MetalLB 運作架構
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 所示）。
圖 2、MetalLB 負載平衡機制 BGP 部署模式運作架構示意圖
實戰 – TCE on vSphere 整合 MetalLB 負載平衡機制
在實戰演練小節中，將帶領管理人員一步一步，把最新版本的 TCE 容器平台部署在 VMware vSphere 7 虛擬化環境中，然後整合輕巧易用功能強大的 MetalLB 負載平衡機制，為屆時運作的眾多容器服務完成網路流量負載平衡的目的。
首先，透過「tanzu cluster」指令，部署「引導叢集」（Bootstrap Cluster），然後部署用於正式營運環境的「託管叢集」（Managed Cluster）架構，當引導叢集建立管理叢集後，便會開始將所有管理物件移動至「管理叢集」（Management Cluster）（如圖 3 所示）。
圖 3、引導叢集部署託管叢集架構中的管理叢集流程示意圖
一旦管理叢集運作架構成形後，系統便會接著部署託管叢集中的「工作負載叢集」（Workload Cluster）。值得注意的是，管理叢集只需要一個即可，並依據需求建立多個不同用途的工作負載叢集（如圖 4 所示）。
圖 4、引導叢集部署管理叢集和工作負載叢集程序示意圖
建構 Tanzu CLI 管理主機
在部署 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 專案頁面手動下載後進行離線安裝。
Windows 主機倘若為 VM 虛擬主機時，管理人員必須啟用 VM 虛擬主機支援 Intel VT-x/EPT 硬體輔助虛擬化功能，否則屆時 Docker Desktop 服務將會啟動失敗。
確認 Chocolatey 套件安裝管理工具，執行下列 PowerShell 指令，即可達成安裝 kubectl、Docker Desktop、Tanzu CLI 的目的（如圖 5 所示），管理人員可以加上「--version」參數，指定希望安裝的版本，舉例來說，本文實作環境中倘若未加上指定版本參數時，預設將會安裝前一版 v0.11 版本，但 TCE 已經於日期發佈最新的 v0.12 版本，此時便可以加上參數安裝指定版本。
管理人員必須先安裝 kubectl 和 Docker Desktop，否則在安裝 Tanzu CLI 的過程中將會因為環境檢查環境，發生缺少相關元件而導致錯誤。
值得注意的是，倘若採用手動下載離線安裝的方式時，必須在安裝好 Tanzu CLI 指令工具後，手動將「C:\Program Files\tanzu」路徑，加入至 Windows 主機環境變數當中。
choco install kubernetes-clichoco install docker-desktopchoco install tanzu-community-edition --version=0.12
圖 5、透過 Chocolatey 工具安裝 kubectl、docker desktop、Tanzu CLI 指令工具
產生 SSH 加密金鑰
部署 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 所示）。
圖 6、啟動 ssh-agent 系統服務並透過 ssh-add 匯入 SSH 私有金鑰
部署 TCE 範本映像檔至 vSphere 虛擬化平台
首先，請確保採用「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 所示）。
圖 7、將 photon-3-kube-v1.22.8 虛擬主機轉換為 VM 範本格式
部署 TCE 管理叢集
請切換至 Tanzu CLI 管理主機，執行「tanzu management-cluster create --ui」指令，系統將會啟動 kickstart UI 進行 TCE 託管叢集初始化部署流程。簡單來說，整個部署流程大約分為二個步驟，第一步是部署 TCE 管理叢集，接著則是部署 TCE 工作負載叢集（如圖 8 所示）。
TCE 安裝程序也支援部署至地端 Docker 容器環境，和 AWS 及 Azure 公有雲環境。
圖 8、TCE 託管叢集初始化部署流程示意圖
在本文實作環境中，請按下 VMware vSphere 區塊中的 Deploy 鈕進行部署作業，在安裝流程步驟一的 IaaS Provider 頁面中，請鍵入 vCenter Server 名稱和管理帳號及密碼後按下 Connect 鈕，通過管理者身份驗證程序後，選擇準備部署 TCE 託管叢集的 vSphere Datacenter，並貼上剛才建立 SSH 加密金鑰中的公開金鑰內容（如圖 9 所示）。
圖 9、鍵入 vCenter 管理平台的管理人員帳號密碼資訊和 Tanzu CLI 主機 SSH Public Key
在 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 所示）。
請注意 ! Management Cluster Name 欄位，目前僅支援「英文小寫」開頭，以及「數字和 - 及 .」，其它字元尚未支援，例如，尚未支援「英文大寫」名稱。
圖 10、組態設定 TCE 託管叢集名稱和控制平面 VIP 位址
在 VMware NSX Advanced Load Balancer 頁面中，可以整合 NSX 進階負載平衡器機制，在本文實作環境中並不需要，請直接按下 Next 鈕至下一個部署流程。在 Metadata 頁面中，目前並不需要額外定義中繼資料，請直接按下 Next 鈕至下一個部署流程。
在 Resources 頁面中，請於 VM Folder 欄位中選擇先前為 TCE 環境建立的 VM 資料夾，本文實作為「/Datacenter/vm/TCE」，在 Datastore 欄位則是選擇要採用的儲存資源，在 Clusters，Hosts，and Resource Pools 欄位，選擇要採用的 vSphere 運算資源，本文實作選擇使用 vSphere 虛擬化環境中準備的「K8s-Cluster」。
在 Kubernetes Network 頁面中，請組態設定 TCE 託管叢集所要使用的 vNetwork 虛擬網路，在 Network Name 欄位中，請選擇使用的 vSphere vSwitch 虛擬交換器，本文實作為「/Datacenter/network/TCE-Network」，至於 Cluster Service CIDR 和 Cluster Pod CIDR 欄位，則是屆時容器會使用到的 IP 位址網路，請採用系統預設值即可。值得注意的是，這些系統預設值網段，倘若和企業或組織內部網路互相衝突時，則需要修改成不同網段。
連接的 vSwitch 虛擬交換器，必須和前述第二步驟中控制平面 VIP 位址同一個網段，並且必須支援 DHCP 自動派發 IP 位址機制。
在 Identity Management 頁面中，管理人員可以組態設定使用者身份驗證機制，目前 TCE 運作環境中支援 OIDC 或 LDAPS 通訊協定，在目前測試用途的 TCE 託管叢集中並不需要，所以直接按下 Next 鈕至下一個部署流程。
在 OS Image 頁面中，便是選擇先前上傳到 vSphere 虛擬化環境中 OVA，並且將 VM 虛擬主機轉換為 VM Template 的印象檔，這便是稍後部署 TCE 託管叢集時，所要採用的 Base OS Image 印象檔。本文實作為「/Datacenter/vm/TCE/photon-3-kube-v1.22.8」。
完成上述八項組態設定後（如圖 11 所示），按下 Review Configuration 鈕，再次檢視組態設定內容是否正確，確認無誤後按下「Deploy Standalone Cluster」鈕，便立即開始 TCE 託管叢集的部署工作任務。在本文實作環境中，大約花費「18 分鐘」時間便部署完成 TCE 託管叢集。
此外，管理人員剛才的所有組態設定，系統將會自動儲存於 Tanzu CLI 主機中，路徑為「${HOME}/.config/tanzu/tkg/clusterconfigs」組態設定檔內，便於管理人員後續查看內容或再次進行部署作業。
圖 11、開始部署 TCE 託管叢集至 vSphere 虛擬化環境
圖 12、確認控制平面主機和工作負載節點主機運作狀態
驗證並連線至 TCE 管理叢集
確認 TCE 託管叢集部署完成並運作正常後，請從 Tanzu CLI 主機鍵入「tanzu login」指令，選擇要連接的管理叢集名稱「tce-cluster」後，系統會採用預設儲存於本機的 kubeconfig 內容，路徑為「C:\Users\Weithenn\.kube\config\tanzu」進行驗證，成功通過驗證程序後，即可看到成功連線至 TCE 管理叢集。接著，鍵入「tanzu management-cluster get」指令，確認 TCE 管理叢集是否已經啟動完成，也就是 READY 欄位是否都顯示為 True（如圖 13 所示）。
圖 13、驗證連線並登入 TCE 管理叢集後，確保管理叢集啟動完成
執行「tanzu management-cluster kubeconfig get tce-cluster --admin」指令，擷取系統中儲存的 TCE 管理叢集 kubeconfig 內容，並且把通過驗證程序的憑證儲存，執行「kubectl config use-context tce-cluster-admin@tce-cluster」指令進行切換叢集作業後，執行「kubectl get nodes」指令，確認 Tanzu CLI 主機已經可以順利跟 TCE 管理叢集的 API 服務進行互動（如圖 14 所示）。
圖 14、查看 K8s 叢集的控制平面和各個節點主機資訊
部署 TCE 工作負載叢集
完成 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 所示）。
圖 15、部署名稱為 workload01 的 TCE 工作負載叢集
當部署作業完成後，切換至 vCenter 管理介面時，同樣可以看到 TCE 工作負載叢集的控制平台和工作節點主機，並且控制平面採用指定的 10.10.75.60 位址，擔任 API Server 的通訊 IP 位址（如圖 16 所示）。
圖 16、確認 TCE 工作負載叢集中控制平面主機和工作負載節點主機運作狀態
部署 MetalLB 負載平衡機制
在部署 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 所示）。
圖 17、部署 MetalLB 運作元件容器建立負載平衡機制
部署 Yelb 訂餐投票網頁服務容器
在容器服務的部份，採用由前 VMware 員工 Massimo ReFerre 所撰寫的 Yelb 應用服務，方便進行範例展示和負載平衡機制實作演練。簡單來說，Yelb 應用服務中，會有採用 Angular 2 技術的 yelb-ui 前端元件容器，負責將 JS code 回應給瀏覽器，另外 yelb-appserver 容器負責讀取和寫入 redis-server 中，而 yelb-db 容器則是運作 PostgreSQL 資料庫，負責將訂餐投票的結果儲存下來（如圖 18 所示）。
圖 18、Yelb 應用服務運作架構示意圖
首先，執行「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 所示）。
圖 19、部署 Yelb 訂餐投票網頁服務容器
此時，開啟瀏覽器鍵入「http://10.10.75.61」，系統便會將這個網頁瀏覽請求，由運作在 TCE 工作負載叢集中的 MetalLB 負載平衡機制，將網頁瀏覽請求轉導向至 Yelb 容器中，負責網頁服務的 yelb-ui 容器中的 Port 30674。管理人員可以隨意按下 VOTE 鈕進行投票，體驗這個 Yelb 訂餐統計範例網頁的功能（如圖 20 所示）。
圖 20、驗證 MetalLB 負載平衡服務將網頁請求導向至 Yelb 訂餐投票網頁服務
