︿
Top


網管人雜誌

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





本文目錄






前言

在先前的專欄內容中,已經說明及實際部署「單一節點」AKS EE 容器叢集。在本文中,將更進一步說明「多台節點」AKS EE 容器叢集的運作架構,並且進行實戰演練的部份,幫助企業和組織內的 IT 管理人員,輕鬆建構出可「橫向擴充」(Scale-Out)的多台節點 AKS EE 容器叢集運作架構(如圖 1 所示)。

圖 1、AKS EE 容器叢集運作架構支援二種不同的部署選項

值得注意的是,單一節點和多台節點 AKS EE 容器叢集,這兩者之間最大不同在於網路環境的部份。舉例來說,在單一節點 AKS EE 容器叢集中,系統將自動建立 Hyper-V Internal 類型 vSwitch 虛擬交換器,並且自動組態設定使用「192.168.0.0/24」的網路環境,並且管理人員無法變更這項預設的網路環境組態。

在多台節點 AKE SS 容器叢集,或稱「可調整叢集」(Scalable Cluster),由於多台節點主機之間必須能夠跨節點通訊,所以改為採用 Hyper-V External 類型 vSwitch 虛擬交換器,達到跨越多台節點主機順利通訊的工作任務(如圖 2 所示)。

圖 2、多台節點 AKS EE 容器叢集網路運作架構示意圖





實戰演練 – 部署多台節點 AKS EE 容器叢集

部署支援巢狀式技術的 VM 虛擬主機

原則上,只要採用支援的硬體主機和作業系統版本,便能部署 AKS EE 多節點容器叢集,然而對於中小型企業和組織來說,管理人員可能沒有多餘且符合軟硬體需求的主機。此時,便可以在內部資料中心內,部署支援巢狀式 VM 虛擬主機環境,或是透過 Azure 公有雲環境,部署支援巢狀式虛擬化環境的 VM 虛擬主機。

值得注意的是,無論是採用內部資料中心或 Azure 公有雲環境,採用支援巢狀式虛擬化環境的 VM 虛擬主機,所建構及部署的 AKS EE 容器叢集,都僅適用於研究和測試用途,不適用於真實營運環境。

在本文實作環境中,將會在一台支援巢狀式虛擬化的 Azure VM 虛擬主機中,建立多台 VM 虛擬主機,達成部署 AKS EE 多節點容器叢集的目的。值得注意的是,Azure VM Gen2 世代虛擬主機,預設在安全性類別採用「Trusted launch virtual machines」選項,以便支援 Secure Boot 和 vTPM 等安全性機制,但卻會導致巢狀式虛擬化機制無法運作。

因此,在建立支援巢狀式虛擬化的 Azure VM 虛擬主機時,記得將安全性類別選擇為「Standard」項目(如圖 3 所示),後續才能確保巢狀式虛擬化技術正常運作,詳細資訊請參考 Azure VM 的可信任啟動 - Azure Virtual Machines | Microsoft Learn 官方文件說明。

圖 3、安全性類別選擇為 Standard 巢狀式虛擬化功能才能順利運作



控制節點安裝 AKS EE 環境

在本文實作環境中共有三台主機,一台擔任 Kubernetes 容器叢集中「控制節點」(Control Plane)的角色,這台控制平面僅負責管理 Kubernetes 容器叢集,並且資源調度另外二台「工作節點」(Worker Nodes)主機,負責運作屆時的 Linux 和 Windows 容器等工作負載。

在 AKS EE 運作架構中,支援 主流 K8s精簡版 K3s,企業和組織可視需求部署其中一個,除了底層和 Kubernetes 運作元件不同之外,在 CNI 網路外掛程式的部份也有所不同,採用 K8s 時 CNI 網路外掛程式為「Calico」,而採用 K3s 時則會採用「Flannel」。

值得注意的是,AKS EE 運作架構雖然同時支援 K8s 和 K3s 容器叢集環境,但無法混合環境使用,舉例來說,控制節點安裝 K3s 容器叢集環境的話,那麼其它接受調度的工作節點也必須安裝 K3s 才行。

由於控制節點僅需運作 Linux VM 主機即可,所以控制節點僅需下載並安裝 K3s 安裝程式即可,請以系統管理員身份開啟 PowerShell,鍵入並執行「msiexec.exe /i AksEdge-k3s-1.27.6-1.6.384.0.msi」指令(如圖 4 所示),執行部署 K3s 容器叢集的動作。

圖 4、Kubernetes 節點主機部署 K3s 容器叢集環境

安裝作業完成後,請執行「Import-Module AksEdge」指令,將 AKS EE 相關的 PowerShell 模組載入至系統中,接著執行「Get-Command -Module AKSEdge | Format-Table Name, Version」指令,確保 AKS EE 的 PowerShell Cmdlet 模組順利載入(如圖 5 所示)。倘若,無法順利載入 AKS EE 相關 PowerShell 模組的話,可以嘗試執行「Set-ExecutionPolicy RemoteSigned -Scope Process -Force」調整 PowerShell 安全性等級後,再次嘗試執行匯入 AKS EE 相關 PowerShell 模組的動作。

圖 5、確認控制節點主機是否順利載入 AKS EE PowerShell 相關模組

請執行「Install-AksEdgeHostFeatures」指令,系統將會自動執行驗證程序,確保 AKS EE 節點主機是否安裝並啟用 Hyper-V、OpenSSH Client……等,倘若系統偵測到主機並未安裝或正確的組態設定時,將會自動執行安裝和啟用等工作任務,並且在完成後自動重新啟動主機。建議管理人員,在 AKS EE 節點主機重新啟動後,再次執行指令確保主機已經滿足所有驗證程序,並會在結尾顯示「True」訊息(如圖 6 所示)。

圖 6、確認 AKS EE 節點主機滿足運作容器叢集的需求



產生並驗證 Kubernetes 叢集組態

事實上,AKS EE 容器叢集運作環境,與 Azure 雲端環境中的 AKS 容器叢集,以及地端的 AKS HCI 容器叢集運作機制不同,因為 AKS 或 AKS HCI 預設便會啟用動態機制,建立或刪除相關的 VM 虛擬主機,以便滿足容器叢集生命週期管理,但 AKS EE 則是屬於「靜態」運作機制,每台 AKS EE 主機只會運作一台 Linux VM 虛擬主機,或者視需求搭配運作一台 Windows VM 虛擬主機,並且由管理人員透過 .json 組態設定檔進行容器叢集的部署作業。

請在 PowerShell 視窗中,執行「New-AksEdgeConfig -DeploymentType ScalableCluster -outFile .\aksedge-config.json」指令,產生用於部署多節點容器叢集,並且名稱為「aksedge-config.json」的 JSON 組態設定檔(如圖 7 所示),內含部署運作控制平面角色的 Linux VM 虛擬主機。

圖 7、產生用於部署多節點容器叢集的 JSON 組態設定檔

下列為本文環境調整後客製化參數的項目及說明,其餘則採用系統預設值即可:
  • DeploymentType: 預設值為「ScalableCluster」,屆時將定義 AKS EE 部署類型為多節點容器叢集。
  • Init.ServiceIPRangeStart: 預設值為「null」,組態設定容器叢集服務 IP 位址的啟始位址,由於多節點容器叢集必須採用靜態 IP 位址,在本文實作環境中啟始位址為「10.10.75.101」。請注意,目前 AKS EE 容器叢集僅支援 IPv4 位址,尚未支援採用 IPv6 位址。
  • Init.ServiceIPRangeSize: 預設值為「0」,表示稍後部署的容器叢集將沒有服務 IP 範圍,屆時運作的容器工作負載,系統不會配置服務 IP 位址,管理人員必須手動使用 Get-AksEdgeNodeAddr 等相關指令,確認 Linux 或 Windows 節點主機的 IP 位址,然後搭配相關通訊埠號,才能存取容器工作負載所提供的服務。本文實作環境調整為「50」,表示組態設定容器叢集服務配置 50 個服務 IP 位址。
  • Network.ControlPlaneEndpointIp: 預設值為「null」,組態設定 Kubernetes 容器叢集中控制平面的 IP 位址,本文實作環境採用「10.10.75.50」。請注意,這個 IP 位址不能和節點主機,或者稍後部署的 Linux VM 虛擬主機採用相同的 IP 位址,否則將會發生 IP 位址衝突的情況。
  • Network.NetworkPlugin: 預設值為「flannel」,由於本文實作環境為安裝及部署 K3s 容器叢集,所以 CNI 網路外掛程式的預設值便為 flannel,倘若部署 K8s 容器叢集則預設值將為 calico 。
  • Network.Ip4GatewayAddress: 預設值為「null」,本文實作環境此網段的預設閘道 IP 位址為「10.10.75.1」。
  • Network.Ip4PrefixLength: 預設值為「24」,AKS EE 容器叢集網路環境的子網路遮罩。
  • Network.DnsServers: 預設值為「」,AKS EE 容器叢集屆時使用的 DNS 名稱解析伺服器不可為空值,否則稍後的部署作業將會產生錯誤並停止部署作業,本文實作組態設定「8.8.8.8」為 DNS 名稱解析伺服器。
  • Machines.NetworkConnection.AdapterName: 預設值為「null」,指定 AKS EE 容器叢集中,Linux VM 虛擬主機使用的實體主機網路介面卡名稱,本文實作為「Ethernet」,倘若不確定網路介面卡名稱,可以執行「Get-NetAdapter -Physical | Where-Object { $_.Status -eq 'Up' }」PowerShell 指令進行確認。
  • Machines.LinuxNode.CpuCount: 預設值為「4」,表示稍後部署的 Linux VM 虛擬主機,將會配置 4 vCPU 虛擬處理器資源。
  • Machines.LinuxNode.MemoryInMB: 預設值為「4096」,表示稍後部署的 Linux VM 虛擬主機,將會配置 4GB vMemory 記憶體空間,本文實作環境調整為「8192」。
  • Machines.LinuxNode.DataSizeInGB: 預設值為「10」,表示稍後部署的 Linux VM 虛擬主機,將會配置 10 GB vDisk 虛擬磁碟空間存放資料。
  • Machines.LinuxNode.LogSizeInGB: 預設值為「1」,表示稍後部署的 Linux VM 虛擬主機,將會配置 1 GB vDisk 虛擬磁碟空間存放日誌。
  • Machines.LinuxNode.Ip4Address: 預設值為「null」,組態設定 Linux VM 虛擬主機使用的 IP 位址,本文實作環境採用「10.10.75.51」。請注意,這個 IP 位址不能和節點主機,以及先前組態設定的控制平台採用相同的 IP 位址,否則將會發生 IP 位址衝突的情況。

多節點容器叢集的 JSON 組態設定檔客製化調整後,請在 PowerShell 視窗中,執行「Test-AksEdgeNetworkParameters -JsonConfigFilePath .\aksedge-config.json」指令,在部署 AKS EE 多節點容器叢集之前,確認 JSON 組態設定檔內容是否正確無誤,例如,內容語法是否正確,組態設定的 IP 位址是否有重複的情況發生……等,當系統檢查內容無誤的話,便會顯示「Network parameter validation terminated successfully」的綠色字體訊息(如圖 8 所示),並且檢查結果為「True」,表示可以放心用於稍後的多節點容器叢集部署工作任務中。

圖 8、驗證 JSON 組態設定檔內容及語法是否正確無誤

倘若,系統驗證 JSON 組態設定檔內容及語法有錯誤時,系統便會顯示「Network parameter validation terminated with above errors」的紅色字體訊息,檢查結果為「False」,表示管理人員應該回頭檢視 JSON 組態設定檔內容及語法,舉例來說,本文實作環境中一開始指定的 DNS 名稱解析伺服器為 10.10.75.1,但是系統檢查後發現,組態設定的的 DNS 名稱解析伺服器,並無法解析 microsoft.com 名稱(如圖 9 所示)。

圖 9、系統檢查出 JSON 組態設定檔內容或語法有錯誤



部署 AKS EE 容器叢集中的控制節點

當 Test-AksEdgeNetworkParameters 指令檢查結果為「True」時,便可以執行「New-AksEdgeDeployment -JsonConfigFilePath .\aksedge-config.json」指令,開始部署 AKE EE 容器叢集架構中的控制節點(如圖 10 所示)。

圖 10、部署 AKE EE 容器叢集架構中的控制節點

在本文實作環境中,花費約 5 分鐘時間,便成功部署擔任控制節點角色的 Linux 節點主機,管理人員可以開啟 Hyper-V 管理員工具,即可看到系統已經自動建立控制節點角色的 Linux 節點主機,並且看到剛才在 JSON 組態設定檔內容中,組態設定控制節點角色使用「10.10.75.50」的 IP 位址,而 Linux 節點主機使用「10.10.75.51」的 IP 位址,並且系統已經在部署過程中,自動建立名稱為「aksedgesw-ext」的 Hyper-V 外部 vSwitch 虛擬交換器(如圖 11 所示)。

圖 11、成功部署擔任控制節點角色的 Linux 節點主機

在執行 New-AksEdgeDeployment 指令的部署過程中,系統會自動擷取 kubeconfig 檔案和處理 Kubernetes 驗證事宜。現在,管理人員可以透過 kubectl 指令,檢查並確認 AKS EE 容器叢集,以及 Linux 節點主機是否運作正常,請在 PowrShell 指令視窗中,執行「kubectl get nodes -o wide」指令,查看 Linux 節點主機運作資訊,執行「kubectl get pods -A -o wide」指令,可以查看 AKS EE 容器叢集中控制平面運作資訊(如圖 12 所示)。

圖 12、透過 kubectl 指令確認 AKS EE 容器叢集和控制主機資訊



部署 AKS EE 容器叢集中的工作節點

在本文實作環境中,將會部署二台工作節點主機,這二台工作節點主機將會同時部署,Linux 和 Windows 節點主機,以便屆時可以同時分擔運作 Linux 和 Windows 容器的工作任務,由於二台工作節點主機的部署方式相同,下列將以第一台「AKSEE-Worker01」為例。

在為工作節點主機安裝 K3s 容器環境時,由於屆時會同時運作 Linux 和 Windows 節點主機,所以必須額外下載 Windows 節點主機檔案(AksEdgeWindows-1.6.384.0.zip),以便後續能夠部署和運作 Windows 容器。

在執行安裝 K3s 環境之前,請將 K3s 安裝程式和解壓後的Windows節點主機檔案,放置在同一個資料夾內或路徑中,並以系統管理員身份開啟 PowerShell,然後執行「msiexec.exe /i AksEdge-K3s-1.27.6-1.6.384.0.msi ADDLOCAL=CoreFeature,WindowsNodeFeature」指令,安裝 K3s 容器環境的混合部署模式(如圖 13 所示)。

圖 13、部署 AKS EE 容器叢集中工作節點的 k3s

同樣的,安裝完成後必須先執行「Import-Module AksEdge」指令,以便載入 AKS EE 相關 PowerShell 模組,執行「Install-AksEdgeHostFeatures」指令,啟用 Hyper-V、SSH…… 等伺服器角色和功能。

當工作節點 Kubernetes 環境準備完畢後,請切換至控制節點主機,產生用於部署 Linux 和 Windows 主機的 JSON 組態設定檔,請執行「New-AksEdgeScaleConfig -scaleType AddMachine -NodeType LinuxandWindows -LinuxNodeIp 10.10.75.61 -WindowsNodeIp 10.10.75.71 -outFile .\ScaleConfig.json」指令(如圖 14 所示),產生部署第一台工作節點主機的 JSON 組態設定檔,其中指定 Linux 主機使用 10.10.75.61 的 IP 位址,而 Windows 主機則使用 10.10.75.71 的 IP 位址。後續部署第二台工作節點主機時,則指定 Linux 主機使用 10.10.75.62 的 IP 位址,而 Windows 主機則使用 10.10.75.72 的 IP 位址。

圖 14、在控制主機產生部署第一台工作節點主機的 JSON 組態設定檔

管理人員產生並複製 JSON 組態設定檔,至二台工作節點主機後,可以嘗試開啟檔案查看內容,原則上和部署控制主機的內容大同小異,不同的地方為多了「Join.ClusterJoinToken」和「Join.ClusterID」,也就是指定 AKS EE 容器叢集的資訊,確保加入對的 AKS EE 容器叢集運作環境中。同樣的,在執行部署之前,建議檢查 JSON 組態設定檔內容和語法正確無誤後(如圖 15 所示),再執行部署工作節點內 Linux 和 Windows 主機的動作。

圖 15、檢查和確認 JSON 組態設定檔內容和語法正確無誤

執行「New-AksEdgeDeployment -JsonConfigFilePath .\ScaleConfig.json」指令,開始部署 AKE EE 容器叢集架構中的工作節點,開啟 Hyper-V 管理員工具,即可看到系統自動建立 Linux 和 Windows 角色的節點主機,以及在 JSON 組態設定檔內容中,指定 Linux 節點主機使用「10.10.75.61」的 IP 位址,而 Windows 節點主機使用「10.10.75.71」的 IP 位址,並且自動建立名稱為「aksedgesw-ext」的 Hyper-V 外部 vSwitch 虛擬交換器(如圖 16 所示)。

圖 16、AKS EE 工作節點順利部署 Linux 和 Windows 節點主機

現在,管理人員可以在 AKS EE 容器叢集中,任一角色的主機上執行「kubectl get nodes -o wide」指令,即可看到除了先前部署的控制節點主機資訊之外,也看到剛才部署的工作節點中,Linux 和 Windows 節點主機的運作資訊,包含 IP 位址、作業系統映像檔……等資訊。在本文實作環境中,請依照同樣的方式,部署第二台工作節點主機,在第二台工作節點的 JSON 組態設定檔內容中,將會指定 Linux 節點主機使用「10.10.75.62」的 IP 位址,而 Windows 節點主機使用「10.10.75.72」的 IP 位址,部署完成後再次查看即可發現,目前 AKS EE 叢集運作架構中,有一台控制節點主機、二台 Linux 工作節點、二台 Windows 工作節點(如圖 17 所示)。

圖 17、順利部署一台控制節點和各二台 Linux 及 Windows 工作節點



部署 Linux 和 Windows 容器應用程式

由於 AKS EE 容器叢集的分散式運作架構已經成形,稍後在部署 Linux 和 Windows 容器應用程式時,管理人員即可看到,運作起來的 Linux 和 Windows 容器應用程式,將會自動分散在不同的 Linux 和 Windows 工作節點主機中,而無須管理人員進行額外的負載平衡設定。

首先,部署 Linux 容器應用程式,採用微軟 azure-vote-front 容器映像檔為範例,此容器映像檔存放在微軟公開的 ACR(Azure Container Registry) 當中,並且部署的 linux-sample.yaml 組態設定檔中,預設指定 nodeSelector 為 Linux,所以系統會自動部署至所有 Linux 節點主機中。

此投票範例應用程式,為採用 .NET 所撰寫的前後端應用程式,後端採用 Key-Value 儲存的Redis,執行部署作業時,只要在 PowerShell 指令視窗中,執行「kubectl apply -f https://raw.githubusercontent.com/Azure/AKS-Edge/main/samples/others/linux-sample.yaml」指令,系統便立即解析 linux-sample.yaml 檔案內容,執行部署前端和後端應用程式的工作任務,並且產生及定義相關的 Kubernetes 物件。

部署作業完成後,執行「kubectl get pods -o wide」指令,即可看到「azure-vote-front」前端應用程式,部署在第一台工作節點上,而「azure-vote-back」後端應用程式,則部署在第二台工作節點中。請查看 STATUS 欄位狀態,倘若狀態為 ContainerCreating 時,只需稍等幾分鐘待運作狀態轉變為 Running 時,表示容器應用程式已經順利啟動並正常運作中。

此範例投票程式,在 linux-sample.yaml 組態設定檔中,已經定義好部署 Kubernetes LoadBalancer 流量負載平衡服務,管理人員可以透過「kubectl get services」指令,確認對外服務 IP 位址是否套用生效,請查看 EXTERNAL-IP 欄位,此欄位一開始會顯示 Pending,稍待一小段時間後便會顯示對外服務 IP 位址,本文實作環境為 10.10.75.101(如圖 18 所示)。

圖 18、部署 Linux 容器應用程式並確認對外服務 IP 位址

請開啟瀏覽器鍵入 10.10.75.101 的 IP 位址,即可連線至 Linux 投票應用程式頁面,可以點選 Cats 或 Dogs 鈕進行投票,或按下 Reset 鈕將投票結果進行重置(如圖 19 所示)。

圖 19、驗證 Linux 投票應用程式是否正確運作

在部署 Windows 容器應用程式的部份,將會部署 ASP .NET 容器應用程式,在 win-sample.yaml部署設定檔中,預設已經指定 nodeSelector 為 Windows,表示將會部署在 Windows 節點主機中。

請在 PowerShell 指令視窗中,執行「kubectl apply -f https://raw.githubusercontent.com/Azure/AKS-Edge/main/samples/others/win-sample.yaml」指令,系統將會解析 win-sample.yaml 內容,執行部署和建立 Kubernetes 相關物件。

執行「kubectl get pods -o wide」指令,確認部署的 Windows 容器應用程式是否順利運作。值得注意的是,由於 ASP .NET 容器映像檔較大,必須視工作節點的網際網路連線頻寬而定,所以部署的 Windows 容器需要一些時間才能順利運作,在本文實作環境中,Windows 容器應用程式,從下載到順利運作共花費 10 分鐘。請執行「kubectl get services」指令,可以看到由於此 Windows 容器應用程式中,Kubernetes 服務類型採用「NodePort」,所以系統並不會自動派發對外服務 IP 位址,但可以看到 Windows 容器應用程式使用的服務通訊埠為 30756(如圖 20 所示)。

圖 20、部署 Windows 容器應用程式並取得使用的服務通訊埠為 30756

此時,只要查詢 Windows 容器應用程式,運作在哪一台 Windows 節點主機,即可透過該台 Windows 節點主機的 IP 位址,搭配 Windows 容器應用程式的服務通訊埠,即可順利連線至 Windows 應用程式頁面,在本文實作環境中,Windows 容器應用程式,部署至第一台 Windows 節點主機中,而服務通訊埠為 30756,所以開啟瀏覽器鍵入 IP 位址加服務通訊埠「https://10.10.75.71:30756」,即可連線存取 Windows 容器應用程式頁面(如圖 21 所示)。

圖 21、連線存取 Windows 容器應用程式頁面





結語

透過本文的深入剖析和實作演練後,相信管理人員除了理解多節點 AKS EE 容器叢集的運作架構之外,透過實作演練更能了解如何實際部署多節點 AKS EE 容器叢集,一旦隨著時間或專案增加,而必須擴充 Linux 和 Windows 工作節點主機時,即可非常輕鬆進行工作節點擴充的工作任務。


文章標籤: ,