網管人雜誌
本文刊載於
網管人雜誌第 187 期 - 2021 年 8 月 1 日出刊，NetAdmin 網管人雜誌
為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology
Learning
技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份
1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。
本文目錄
前言
在最新舉辦的 Microsoft Build 2021 大會中，微軟 CEO Satya Nadella 在 Opening Keynote 議程中，正式宣佈 AKS（Azure Kubernetes Service）on Azure Stack HCI 產品，脫離技術預覽階段成為正式服務。簡單來說，這表示微軟官方已經正式為企業和組織，提供地端環境運作 Kubernetes 叢集的技術支援。
事實上，在 AKS on Azure Stack HCI 成為正式服務之前，前前後後已經發佈五個公開技術預覽版本，以便收集使用者意見反應和回饋後，進行相關問題修正和提升使用者操作體驗。
因此，企業和組織的管理人員，將傳統單體的營運服務打包為容器化工作負載之後，或將資料中心內部客製化的 Linux 或 Windows 容器映像檔，在無須進行任何更改的情況下，除了可以隨時部署至 Azure 公有雲環境之外。現在，也可以輕鬆部署至地端資料中心內，自行建構的 AKS on Azure Stack HCI 叢集環境中，達到真正混合雲部署和管理工作負載的目的（如圖 1 所示）。
圖 1、AKS（Azure Kubernetes Service）on Azure Stack HCI 叢集架構運作示意圖
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 虛擬主機即可。
採用 Dv3 和 Ev3 系列的 Azure VM 虛擬主機，便能支援和啟用巢狀式虛擬化技術。
圖 2、AKS on Azure Stack HCI 部署模式示意圖
值得注意的是，企業和組織在地端資料中心內，自行部署 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 所示）。
圖 3、地端資料中心自建 AKS on Azure Stack HCI 叢集環境運作架構示意圖
高可用性機制
在傳統的 Kubernetes 叢集中，運作工作負載叢集和 Pods 及容器的主機，並沒有線上不中斷遷移至其它節點主機的概念和機制。然而，企業和組織在地端資料中心內，建立的 AKS on Azure Stack HCI 叢集環境，由於 AKS 容器服務基礎架構是搭建在 HCI 超融合叢集之上，底層預設是以「容錯移轉叢集」（Failover Cluster）機制所建立，並且針對 AKS 管理叢集和工作負載叢集，將會自動啟用「即時遷移」（Live Migration）機制。
因此，當 AKS 管理叢集和工作負載叢集的底層基礎架構，發生各種預期的中斷服務事件時，運作容器和應用程式的 AKS 工作負載叢集主機，將會透過內建原生的容錯移轉機制，在 HCI 超融合叢集基礎架構中，線上不中斷的將 AKS 工作負載叢集主機，遷移至健康狀態良好的 HCI 超融合叢集節點主機上（如圖 4 所示），所以會比傳統僅將應用程式運作在 VM 虛擬主機上，在進行遷移時花費更少的時間，便能讓容器和應用程式恢復運作。簡單來說，使用者和應用程式都不會察覺到有停機時間的事件發生。
圖 4、AKS on Azure Stack HCI 線上遷移機制支援 AKS 管理和工作負載叢集示意圖
管理人員可能仍然有些許疑惑，那麼我們以三個最常見的中斷服務事件來說明，當中斷服務事件發生時，是否對於 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 容器和應用程式都會受到影響並產生停機時間。
圖 5、線上遷移和 K8s 叢集管理工作節點 Pod 排程調度示意圖
安全性機制
除了高可用性和彈性架構之外，另一個企業和組織重視的「安全性」（Security）議題也不馬虎。透過下列不同的安全性層面說明（如圖 6 所示），讓管理人員能夠更深入理解 AKS on Azure Stack HCI 叢集架構，如何完整且高安全性的保護整體基礎架構。
1. 在 AKS on Azure Stack HCI 叢集架構中，雖然處於管理叢集中的 AKS 主機，可以管理和存取 Kubernetes 叢集中所有的工作負載，但這可能導致單一入侵點的安全性疑慮。然而，實際上 AKS 主機的管理和存取權限會受到管控，因為管理叢集中 AKS 主機的主要用途，僅限於部署容器工作負載和收集並匯整叢集使用量。
2. 雖然，為了降低部署難度和複雜性，工作負載叢集會共用相同基礎的 Windows 伺服器。然而，在基礎安全性需求的情況下，當工作負載叢集共用相同基礎的 Windows 伺服器時，會將每個工作負載叢集部署為 VM 虛擬主機，確保每個工作負載叢集之間有強式隔離機制存在。
3. 管理人員將營運服務以容器的方式，部署並運作在工作負載叢集中，不同容器彼此之間是互相隔離的。雖然，相較於 VM 虛擬主機層級的強式隔離機制來說，容器隔離機制較弱，但是仍保有一定程度的隔離性和安全性。
4. 雖然，容器之間可以透過 Overlay 網路互相通訊和溝通。但是，管理人員可以組態設定 Calico 網路原則，定義在工作負載叢集內運作的 Linux 和 Windows 容器之間，網路封包進出時允許放行或進行阻擋的隔離原則。
5. AKS on Azure Stack HCI 叢集架構中，預設便已經建立憑證的部署及更新和撤銷機制，以便提供內建 Kubernetes 元件之間的通訊，例如，AKS 管理叢集當中的 API 伺服器，與 AKS 工作負載叢集中的容器主機，預設便會透過憑證進行加密通訊。
6. 管理人員無論是透過 kubectl 和 PowerShell 指令，或是 WAC 和 Azure Arc 管理機制與 API 伺服器通訊時，必須先通過 Windows 基礎架構中的 AD 使用者身份驗證機制才行。
7. 微軟官方將會針對每個 AKS on Azure Stack HCI 版本，定期提供適當的安全性修補程式。
圖 6、AKS on Azure Stack 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 管理叢集，或遭遇非預期的錯誤。
圖 7、確認 HCI 超融合叢集已運作正常並註冊至 Azure 公有雲環境
值得注意的是，在 WAC（Windows Admin Center）管理主機，必須採用「Windows 10」作業系統才行，主要原因在於倘若採用 Windows Server 安裝 WAC 服務後，將會因為預設自動運作的 WAC Gateway 模式，造成部署 AKS 容器服務可能發生失敗的情況。
請注意 !部署 GA 版本的 AKS 容器服務，必須採用 Windows Admin Center「2103.2」 或後續版本。
請在 WAC 管理介面中，依序點選「Settings > Gateway > Extensions > Installed extensions」項目，確認在已安裝擴充模組頁面中，看到「Azure Kubernetes Service」項目和版本，確保屆時能夠順利部署 AKS 管理叢集和 AKS 工作負載叢集（如圖 8 所示）。
圖 8、確認 WAC 主機已安裝 AKS 容器服務擴充模組
AKS 管理叢集和 AKS 工作負載叢集
在部署 AKS 工作負載叢集時，正式的 GA 版本和先前的技術預覽版本之間，最大的不同點在於 AKS 管理叢集虛擬網路的部份，由先前技術預覽版本僅支援「Flannel」網路功能，到正式版本時更新增支援「Calico」網路功能（如圖 9 所示）。
簡單來說，Flannel 是專為容器設計的虛擬網路層，它會建立一個「Overlay」網路，讓屆時運作在 AKS 叢集中的 Pod 和容器，都會在 Overlay 網路中獲得 IP 位址，並且可以透過獲得的 IP 位址達到互相通訊的目的。至於 Calico 虛擬網路層除了支援容器之外，還同時支援 VM 虛擬主機和原生主機型工作負載，並且支援 「Network Policies」（網路原則） 功能，以便管理容器和 Pod 之間的網路流量，達到安全性管控的目的。
圖 9、部署 AKS 管理叢集並採用和整合 Calico 虛擬網路層
順利部署 AKS 管理叢集和工作負載叢集後，可以在 WAC 管理介面中看到 Kubernetes 叢集健康情況和版本。在本文實作環境中，可以看到 AKS 管理叢集採用穩定的「v1.19.7」版本，而 AKS 工作負載叢集則是採用最新的「v1.20.5」版本（如圖 10 所示）。
圖 10、確保 AKS 管理叢集和工作負載叢集的健康情況和版本資訊
部署 Linux 和 Windows 節點主機
確認 AKS 管理叢集和 AKS 工作負載叢集部署完成後。由於，在剛才部署 AKS 工作負載叢集時，為了加快部署速度，並沒有在部署過程中順便建立 Linux 或 Windows 節點主機。
在部署 Linux 或 Windows 節點主機之前，管理人員可以透過「Get-AksHciKubernetesVersion」指令，查詢每個 Kubernetes 版本資訊和支援的作業系統（如圖 11 所示）。
圖 11、查詢目前環境支援的每個 Kubernetes 版本資訊和支援的作業系統
現在，管理人員可以透過「Set-AksHciCluster」指令，搭配參數「-Name k8s-workload-cluster」指定 AKS 工作負載叢集，搭配參數「-linuxNodeCount 1」指定部署一台 Linux 節點主機，搭配參數「-windowsNodeCount 1」指定部署一台 Windows 節點主機。待部署作業完成後，透過「Get-AksHciCluster」指令，查詢指定的 AKS 工作負載叢集和 Linux 及 Windows 節點主機資訊（如圖 12 所示）。
圖 12、部署 Linux 及 Windows 節點主機至指定的 AKS 工作負載叢集
部署 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 位址。
請注意 !一開始執行部署作業時，EXTERNAL-IP 欄位將是「pending」狀態，待部署完成且正確連接至 AKS 工作負載叢集的負載平衡器後，系統便會顯示可供使用者存取應用程式的 IP 位址。
圖 13、部署 Linux 容器和應用程式至 AKS 工作負載叢集
現在，使用者可以透過瀏覽器存取 Azure 投票應用程式，本文實作環境 IP 位址為「10.10.75.93」（如圖 14 所示），使用者可以隨意投票給 Dogs 或 Cats 或按下 Reset 鈕清除投票結果。
圖 14、透過瀏覽器存取 Azure 投票應用程式
部署 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 位址（如圖 15 所示），便是稍後存取 ASP.NET 範例網站應用程式的 IP 位址。
圖 15、部署 Windows 容器和應用程式至 AKS 工作負載叢集
現在，使用者可以透過瀏覽器存取 ASP.NET 範例網站，本文實作環境 IP 位址為「10.10.75.93」（如圖 16 所示）。
圖 16、透過瀏覽器存取 ASP.NET 範例網站
調整 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 個」（如圖 17 所示）。
圖 17、即時調整 Linux 或 Windows 容器服務的運作規模
結語
透過本文的深入剖析及實戰演練，除了管理人員可透過 WAC 管理平台，輕鬆部署 AKS 容器服務和控制平面基礎架構，以及 Kubernetes 叢集和 Linux 與 Windows 節點主機，和同時部署 Linux 和 Windows 容器及應用程式之外，透過底層 HCI 超融合叢集的容錯移轉機制，更能夠為上層運作的容器及應用程式，提供傳統 Kubernetes 叢集所無法提供的高可用性。
