網管人 198 期 - 實戰 TCE 託管工作負載叢集整合 MetalLB 負載平衡機制



網管人雜誌

本文刊載於 網管人雜誌第 198 期 - 2022 年 7 月 1 日出刊,NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它,或透過城邦出版人讀者服務網進行訂閱。





本文目錄

          產生 SSH 加密金鑰
          部署 TCE 管理叢集





前言

先前的技術專欄中,已經實作適用於研發和測試環境,建構基於 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-cli
choco install docker-desktop
choco 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 虛擬化環境

當 TCE 託管叢集部署作業完成後,切換至 vSphere 虛擬化環境中,從 vCenter 管理介面可以看到,已經部署完成二台 VM 虛擬主機,其中一台為 TCE 託管叢集的控制平面主機,名稱開頭為「tce-cluster-control-plane」,另一台則是屆時運作各式容器的工作負載節點主機。此外,剛才部署流程中設定的控制平台 VIP 位址「10.10.75.50」,也已經由系統自動設定至控制平面主機(如圖 12 所示)。

圖 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 訂餐投票網頁服務





結語

透過本文的深入剖析和實作演練,管理人員可以逐步建立 TCE 託管叢集運作架構,包括 TCE 管理叢集和工作負載叢集,接著部署 MetalLB 負載平衡機制和 Yelb 訂餐統計範例容器,快速體驗 MetalLB 負載平衡機制帶來的強大便利性。