透過本文的深入剖析和實作，管理人員除了理解多節點AKS EE容器叢集的運作架構外，再經由實作演練更能了解如何實際部署多節點AKS EE容器叢集，一旦隨著時間或專案增加而必須擴充Linux和Windows工作節點主機時，即可非常輕鬆進行工作節點擴充的工作任務。
在先前的專欄內容中，已經說明及實際部署「單一節點」AKS EE容器叢集。本文將更進一步說明「多台節點」AKS EE容器叢集的運作架構，並且進行實戰演練，幫助企業和組織內的IT管理人員輕鬆建構出可「橫向擴充」（Scale-Out）的多台節點AKS EE容器叢集運作架構，如圖1所示。
圖1 AKS EE容器叢集運作架構支援二種不同的部署選項。 （圖片來源：AKS Edge Essentials叢集和節點 - AKS hybrid | Microsoft Learn）
值得注意的是，單一節點和多台節點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 Edge Essentials網路功能 - AKS hybrid | Microsoft Learn）
說明之後，接著就來實際部署多台節點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虛擬主機將會配置10GB vDisk虛擬磁碟空間存放資料。
‧Machines.LinuxNode.LogSizeInGB：預設值為「1」，表示稍後部署的Linux VM虛擬主機將配置1GB 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容器應用程式頁面。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞