微軟正式支援地端K8s叢集　實戰AKS-HCI混合部署

在最新舉辦的Microsoft Build 2021大會中，微軟CEO Satya Nadella在Opening Keynote議程中，正式宣佈AKS（Azure Kubernetes Service）on Azure Stack HCI產品脫離技術預覽階段成為正式服務。簡單來說，這表示微軟官方已經正式提供地端環境運作Kubernetes叢集的技術支援。

企業和組織的管理人員將傳統單體的營運服務打包為容器化工作負載之後，或將資料中心內部客製化的Linux或Windows容器映像檔，在無須進行任何更改的情況下，除了可以隨時部署至Azure公有雲環境外，現在也能夠輕鬆地部署在地端資料中心內，自行建構的AKS on Azure Stack HCI叢集環境中，達到真正混合雲部署和管理工作負載的目的，如圖1所示。

AKS on Azure Stack HCI部署模式

簡單來說，企業在選擇AKS on Azure Stack HCI部署模式時，一共有兩種不同的部署模式可供選擇，如圖2所示。第一種是建立「正式」營運環境的AKS on Azure Stack HCI部署模式，除了必須採用通過硬體驗證程序的實體伺服器外，還要搭配專門為HCI超融合叢集環境進行最佳化和客製化打造的Azure Stack HCI雲端作業系統。

倘若企業目前僅希望「體驗」AKS on Azure Stack HCI運作架構和環境，那麼採用單台伺服器安裝Windows Server 2019作業系統，結合巢狀式虛擬化技術，便可以模擬及搭建AKS on Azure Stack HCI運作環境。甚至，企業組織在內部資料中心沒有多餘的硬體伺服器情況下，直接在Azure公有雲環境中建立一台支援巢狀式虛擬化技術的Azure VM虛擬主機即可。

值得注意的是，企業在地端資料中心內自行部署AKS on Azure Stack HCI叢集環境時，與Azure公有雲環境的AKS容器服務有些許不同。舉例來說，在Azure公有雲環境的AKS容器服務運作架構中，AKS管理叢集中的控制平面底層基礎架構，皆由Azure公有雲環境的VM虛擬主機運作和管理，企業的管理人員無須擔心AKS管理叢集的相關管理事宜，只要操心後續建立的AKS工作負載叢集，以及採用哪些容器映像檔來部署Pod和容器及應用程式。

然而，在地端資料中心自建的AKS on Azure Stack HCI叢集環境中，管理人員必須全面管理整個AKS容器服務的基礎架構，從一開始的Azure Stack HCI超融合叢集環境，到部署AKS容器服務控制平面的「管理叢集」（Management Cluster），以及屆時承載企業營運服務容器化應用程式的「工作負載叢集」（Workload Cluster），這兩個主要的AKS容器服務叢集和負載平衡機制，屆時都會以VM虛擬主機的方式，運作在Azure Stack HCI超融合叢集當中，由管理人員全權管理和維運，如圖3所示。

高可用性機制

在傳統的Kubernetes叢集中，運作工作負載叢集和Pods及容器的主機，並沒有線上不中斷遷移至其他節點主機的概念和機制。然而，企業和組織在地端資料中心內建立的AKS on Azure Stack HCI叢集環境，由於AKS容器服務基礎架構是搭建在HCI超融合叢集之上，底層預設是以「容錯移轉叢集」（Failover Cluster）機制所建立，並且針對AKS管理叢集和工作負載叢集，將會自動啟用「即時遷移」（Live Migration）機制。

因此，當AKS管理叢集和工作負載叢集的底層基礎架構，發生各種預期的中斷服務事件時，運作容器和應用程式的AKS工作負載叢集主機，將會透過內建原生的容錯移轉機制，在HCI超融合叢集基礎架構中，線上不中斷地將AKS工作負載叢集主機，遷移至健康狀態良好的HCI超融合叢集節點主機上，如圖4所示。所以，會比傳統僅將應用程式運作在VM虛擬主機上，在進行遷移時花費更少的時間，便能讓容器和應用程式恢復運作。簡單來說，使用者和應用程式都不會察覺到有停機時間的事件發生。

管理人員可能仍然有些許疑惑，這裡以三個最常見的中斷服務事件來說明，當中斷服務事件發生時，是否對於VM虛擬主機內的應用程式，以及AKS容器和應用程式的可用性造成影響。

首先，在HCI超融合叢集節點主機套用重要安全性更新且必須重新啟動時，由於內建的容錯移轉叢集高可用性機制已啟動，所以當HCI超融合叢集節點主機更新完成並重新啟動之前，將會把主機內所有具備高可用性角色的工作負載，透過即時遷移機制線上不中斷地遷移至其他HCI超融合叢集節點主機，所以無論是VM虛擬主機或AKS容器和應用程式都不會受到任何影響。

當運作AKS工作負載叢集的VM虛擬主機，需要套用安全性更新並且必須重新啟動時，容錯移轉叢集的高可用性機制，將針對AKS工作負載叢集的VM虛擬主機，執行高可用性機制的清空和隔離工作任務，相關的Pod和容器都會收回至可用的工作節點主機，並且在AKS工作負載叢集主機更新作業完成後，重新加入工作節點並進行工作排程調度，如圖5所示。因此，在AKS工作負載叢集VM虛擬主機的層級來說，並不會有產生任何停機事件或受到任何影響，但是從AKS容器和應用程式的層級來看，容器執行收回至可用工作節點的動作，可能會讓應用程式的存取受到影響。

最後，當底層基礎架構的HCI超融合叢集節點主機，發生非預期的硬體故障事件時，容錯移轉叢集會將相關工作負載置於隔離狀態，然後在6～8分鐘的時間之內，為這些受影響的VM虛擬主機執行「快速遷移」（Quick Migration），至HCI超融合叢集中其他仍然存活的節點主機，此時AKS工作負載叢集VM虛擬主機以及AKS容器和應用程式都會受到影響並產生停機時間。

安全性機制

除了高可用性和彈性架構外，另一個企業重視的「安全性」（Security）議題也不馬虎。透過下列不同的安全性層面說明，如圖6所示，讓管理人員能夠更深入理解AKS on Azure Stach HCI叢集架構，如何完整且高安全性的保護整體基礎架構：

1. 在AKS on Azure Stach HCI叢集架構中，雖然處於管理叢集中的AKS主機，可以管理和存取Kubernetes叢集中所有的工作負載，但這可能導致單一入侵點的安全性疑慮。然而，實際上AKS主機的管理和存取權限會受到管控，因為管理叢集中AKS主機的主要用途，僅限於部署容器工作負載和收集並匯整叢集使用量。

2. 雖然為了降低部署難度和複雜性，工作負載叢集會共用相同基礎的Windows伺服器。然而，在基礎安全性需求的情況下，當工作負載叢集共用相同基礎的Windows伺服器時，會將每個工作負載叢集部署為VM虛擬主機，確保每個工作負載叢集之間有強式隔離機制存在。

3. 管理人員將營運服務以容器的方式，部署並運作在工作負載叢集中，不同容器彼此之間是互相隔離的。雖然相較於VM虛擬主機層級的強式隔離機制來說，容器隔離機制較弱，但是仍保有一定程度的隔離性和安全性。

4. 雖然容器之間可以透過Overlay網路互相通訊及溝通，但是管理人員可以組態設定Calico網路原則，定義在工作負載叢集內運作的Linux和Windows容器之間，網路封包進出時允許放行或進行阻擋的隔離原則。

5. AKS on Azure Stach HCI叢集架構中，預設便已經建立憑證的部署及更新和撤銷機制，以便提供內建Kubernetes元件之間的通訊，例如AKS管理叢集當中的API伺服器，與AKS工作負載叢集中的容器主機，預設便會透過憑證進行加密通訊。

6. 管理人員無論透過kubectl和PowerShell指令，或是WAC和Azure Arc管理機制與API伺服器通訊時，必須先通過Windows基礎架構中的AD使用者身分驗證機制才行。

7. 微軟官方會針對每個AKS on Azure Stach HCI版本，定期提供適當的安全性修補程式。

混合部署Linux/Windows容器至AKS-HCI

由於先前在網管人雜誌183期「WAC管理混合雲工作負載，輕鬆部署K8s叢集及容器」專欄文章中，已經介紹過如何將AKS容器服務建置在地端資料中心內的HCI超融合叢集運作環境，所以這裡就不再贅述。

接著，將實戰演練如何在AKS容器服務建構的Kubernetes叢集中，混合部署Windows和Linux容器及應用程式，確保企業打包和客製化的Windows容器及應用程式，能夠正確運作在Windows Worker節點主機上，而非Linux Worker節點主機，避免造成Windows容器和應用程式運作異常。

Azure Stack HCI超融合叢集環境

在開始實作之前，應先確認Azure Stack HCI超融合叢集環境是否運作正常，以便屆時能夠提供給AKS容器服務高效能和高可用性的基礎架構。在本文實作環境中，採用的網域名稱為「hci.weithenn.org」，並且提供運作環境DNS名稱解析和DHCP伺服器服務，而HCI超融合叢集中的節點主機，採用最新版本的Azure Stack HCI 20H2雲端作業系統，建立的HCI超融合叢集名稱為「aks-hci-cluster.hci.weithenn.org」，如圖7所示。此外須注意的是，必須將HCI超融合叢集註冊並連結至Azure公有雲環境，否則稍後無法部署AKS管理叢集，或遭遇非預期的錯誤。

必須留意的是，在WAC（Windows Admin Center）管理主機，必須採用「Windows 10」作業系統才行，主要原因在於倘若採用Windows Server安裝WAC服務後，將會因為預設自動運作的WAC Gateway模式，造成部署AKS容器服務可能發生失敗的情況。

在WAC管理介面中，依序點選「Settings > Gateway > Extensions > Installed extensions」項目，確認在已安裝擴充模組頁面中，看到「Azure Kubernetes Service」項目和版本，確保屆時能夠順利部署AKS管理叢集和AKS工作負載叢集，如圖8所示。

AKS管理叢集和AKS工作負載叢集

在部署AKS工作負載叢集時，正式的GA版本與先前的技術預覽版本，最大的不同點在於AKS管理叢集虛擬網路的部分，由先前技術預覽版本僅支援「Flannel」網路功能，到正式版本時更新增支援「Calico」網路功能，如圖9所示。

簡單來說，Flannel是專為容器設計的虛擬網路層，它會建立一個「Overlay」網路，讓屆時運作在AKS叢集中的Pod和容器，都會在Overlay網路中獲得IP位址，並且可以透過獲得的IP位址達到互相通訊的目的。至於Calico虛擬網路層，除了支援容器外，還同時支援VM虛擬主機和原生主機型工作負載，並且支援「Network Policies」（網路原則）功能，以便管理容器和Pod之間的網路流量，達到安全性管控的目的。

順利部署AKS管理叢集和工作負載叢集後，可以在WAC管理介面中看到Kubernetes叢集健康情況和版本。在本文實作環境中，看到AKS管理叢集採用穩定的「v1.19.7」版本，而AKS工作負載叢集則採用最新的「v1.20.5」版本，如圖10所示。

部署Linux和Windows節點主機

確認AKS管理叢集和AKS工作負載叢集部署完成後，而在剛才部署AKS工作負載叢集時，由於為了加快部署速度，並沒有在部署過程中順便建立Linux或Windows節點主機。

在部署Linux或Windows節點主機之前，可以透過「Get-AksHciKubernetesVersion」指令來查詢每個Kubernetes版本資訊和支援的作業系統，如圖11所示。

現在管理人員可以透過「Set-AksHciCluster」指令，搭配參數「-Name k8s-workload-cluster」指定AKS工作負載叢集，搭配參數「-linuxNodeCount 1」指定部署一台Linux節點主機，搭配參數「-windowsNodeCount 1」指定部署一台Windows節點主機。待部署作業完成後，執行「Get-AksHciCluster」指令來查詢指定的AKS工作負載叢集和Linux及Windows節點主機資訊，如圖12所示。

部署Linux容器和應用程式

首先，將部署Azure投票應用程式（azure-vote.yaml）至AKS工作負載叢集中，這個Azure投票應用程式採用Python/Flask等前端介面技術，而後端資料元件的部分則採用Redis，詳細資訊請參考GitHub - Azure-Samples/azure-voting-app-redis: Azure voting app used in docs文章內容。

在開始部署Linux和Windows容器及應用程式之前，由於稍後將使用kubectl指令，部署容器至AKS工作負載叢集中，所以必須先使用「Get-AksHciCredential」指令，指定kubectl指令的kubeconfig組態設定檔，以及指定的AKS工作負載叢集，否則稍後部署Linux或Windows容器時會遭遇到「x509 : certificate signed by unknown authority」的錯誤訊息並且部署失敗。

準備好「azure-vote.yaml」的YAML檔案內容後，執行「kubectl apply -f azure-vote.yaml」指令，部署「azure-vote-front」和「azure-vote-back」應用服務至AKS工作負載叢集。當部署作業完成後，可以透過「kubectl get deployments」查詢AKS工作負載叢集Deployment狀態，使用「kubectl get pods」查詢部署的Pods狀態，最後使用「kubectl get services」查詢部署後的Services狀態，其中「EXTERNAL-IP」欄位中的IP位址，如圖13所示，便是稍後存取Azure投票應用程式的IP位址。

現在可以透過瀏覽器存取Azure投票應用程式，本文實作環境IP位址為「10.10.75.93」，如圖14所示，使用者可以隨意投票給Dogs或Cats或按下〔Reset〕按鈕清除投票結果。

部署Windows容器和應用程式

在Windows容器的部分，將部署ASP.NET範例網站應用程式（sample.yaml）至AKS工作負載叢集中。同樣地，如果部署Windows容器的目標AKS工作負載叢集，與剛才部署Linux容器不同時，仍然必須先使用「Get-AksHciCredential」指令，指定kubectl指令所要採用的kubeconfig組態設定檔，以及指定的AKS工作負載叢集，否則稍後部署Windows容器時，便會遭遇到「x509 : certificate signed by unknown authority」的錯誤訊息並且部署作業失敗。

準備好「sample.yaml」的YAML檔案內容後，執行「kubectl apply -f sample.yaml」指令，部署「sample」應用服務至AKS工作負載叢集。當部署作業完畢，管理人員可以透過「kubectl get deployments」查詢AKS工作負載叢集Deployment狀態，使用「kubectl get pods」查詢部署的Pods狀態，最後使用「kubectl get services」查詢部署後的Services狀態，其中「EXTERNAL-IP」欄位中的IP位址，便是稍後存取ASP.NET範例網站應用程式的IP位址。

現在使用者可以透過瀏覽器存取ASP.NET範例網站，本文實作環境IP位址為「10.10.75.93」。

調整Pod運作規模

順利部署Linux或Windows容器和應用程式後，管理人員可以隨時依照使用者存取和Pod工作負載情況，隨時調整Linux或Windows容器服務的運作規模。

舉例來說，先前部署的Azure投票應用程式Linux容器中，僅分別部署一個Pod來運作azure-vote-front和azure-vote-back工作負載，當工作負載壓力增大時，可以搭配參數「scale --replicas=5」，將指定的Pod數量從原本的「1個」提升數量為「5個」，而工作負載壓力降低時，也能夠透過參數「scale --replicas=3」，將指定的Pod數量從提升後的「5個」降低數量為「3個」。

結語

透過本文的深入剖析及實戰演練，除了管理人員可透過WAC管理平台，輕鬆部署AKS容器服務和控制平面基礎架構，以及Kubernetes叢集和Linux與Windows節點主機，並同時部署Linux和Windows容器及應用程式之外，透過底層HCI超融合叢集的容錯移轉機制，更能夠為上層運作的容器及應用程式，提供傳統Kubernetes叢集所無法提供的高可用性。

＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞