網管人雜誌
本文刊載於
網管人雜誌第 183 期 - 2021 年 4 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution
Learning 解決方案、Technology Learning
技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份
1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。
本文目錄
前言
隨著新一代的 HCI 超融合雲端作業系統「Azure Stack HCI」發佈，微軟官方也不斷增強 Azure Stack HCI 基礎架構，並且支援更多運作環境的整合運用。事實上，原有的 HCI 超融合叢集環境，主要運作的工作負載是以 VM 虛擬主機為主，當企業和組織需要運作容器時，管理人員可以在 Linux 或 Windows 虛擬主機當中，部署 Docker 或其它容器引擎達到運作和管理數個容器的目的，然而這樣的運作情境，通常僅適用於少量容器工作負載的情況，例如，研發和測試環境。
因此，考量企業和組織的正式營運環境，管理人員需要真正的容器管理調度平台，以便快速啟動 Linux 及 Windows 容器，同時能夠自動化管理容器的生命週期和自動延展，而 Kubernetes 則是目前所公認最佳的容器管理調度平台。
隨著 Azure 公有雲環境上，AKS（Azure Kubernetes Service）容器服務的成熟，微軟官方決定為管理人員提供一致的操作管理體驗，將 Azure 公有雲環境上的 AKS 容器服務，落地運作在 HCI 超融合叢集環境中（如圖 1 所示）。
微軟官方也預告，後續將會有更多 Azure 公有雲服務，支援落地運作在 HCI 超融合叢集中。
圖 1、Azure Stack HCI 超融合叢集支援 AKS 容器服務示意圖
企業和組織的管理人員，除了方便將營運服務的容器化工作負載達成一致性之外，打包客製化好的 Linux 或 Windows 容器映像檔，無須進行任何更改即可隨時部署於 Azure 公有雲環境，以及地端資料中心內建構的 HCI 超融合叢集環境中，達到真正混合雲部署和管理工作負載的目的。
管理人員可以透過 PowerShell 指令進行管理，也可以採用 WAC（Windows Admin Center）管理平台，達到部署和管理 AKS 容器服務和容器工作負載的目的。當管理人員需要建立 Kubernetes 叢集時，只要在 WAC 管理介面中按下 Add 新增按鈕，即可看到支援部署 Kubernetes 叢集的選項（如圖 2 所示）。
請注意，目前 AKS on Azure Stack HCI 仍然處於「公開預覽」（Public Preview）狀態。
圖 2、透過 WAC 管理平台部署 Kubernetes 叢集
AKS on Azure Stack HCI 儲存架構
在 Kubernetes 叢集運作架構中，管理人員已經知道「Pod」是最小的工作負載運算資源單位，每個 Pod 可以包含 1 個或多個容器化的應用程式，而「持續性磁碟區」（Persistent Volumes）則是 Kubernetes 叢集中，容器使用儲存資源的基本單位，當 Pod 裡運作的容器需要儲存資源時，Kubernetes 叢集便會執行調度任務讓容器存取持續性磁碟區儲存資源。
事實上，為了達成支援各類儲存供應商，將儲存資源提供給 Kubernetes 叢集中的容器使用，在 Kubernetes 叢集中提供「容器儲存介面」（Container Storage Interface，CSI）機制，以便儲存供應商能夠撰寫各類 CSI 驅動程式，進而讓 Kubernetes 叢集能夠透過 CSI 機制存取外部儲存資源，舉例來說，在 Azure 公有雲環境的 AKS 容器服務中，當 Kubernetes 叢集內的容器需要存取儲存資源時，AKS 容器服務的控制平台，便會自動安裝二個 CSI 驅動程式「azureDisk」和「azureFile」，其中 azureDisk 用於存取 Azure Disks，而 azureFile 則用於存取 Azure Files 儲存資源。
了解 AKS 容器服務的持續性磁碟區儲存資源之前，先說明 Azure Stack HCI 超融合儲存基礎架構（如圖 3 所示），以幫助管理人員逐步了解 HCI 超融合叢集，如何將高效能高可用性的儲存資源，轉換成為持續性磁碟區儲存資源給容器工作負載使用。下列為傳統 VM 虛擬主機，使用 HCI 超融合叢集儲存資源的步驟：
1. 採用通過 Azure Stack HCI 硬體認證的 x86 硬體伺服器，部署和建構 Azure Stack HCI 超融合叢集。
2. Azure Stack HCI 節點伺服器之間，透過 10Gb、25Gb、40Gb、50Gb、100Gb……等高速乙太網路互相連接，以便 HCI 超融合叢集節點主機之間快速交換和同步資料區塊。
3. 每台 Azure Stack HCI 節點伺服器，都將貢獻本機端的 NVMe、SSD、HDD 儲存裝置，並整合 S2D（Storage Spaces Direct）技術後，進而匯整成為高效能和高可用性的巨大儲存資源。
4. 順利匯整儲存資源之後，管理人員依據需求切割出 VM 虛擬主機需要的「磁碟區」（Volume）儲存資源，包括，定義磁碟區的容錯等級和儲存空間大小……等資訊。
5. 在 HCI 超融合叢集中運作的 VM 虛擬主機，於部署 VM 虛擬主機的過程中，建立 VHDX 虛擬硬碟時指向並掛載至剛才所建立的磁碟區。
6. 運作於 HCI 超融合叢集上層的 VM 虛擬主機，掛載 VHDX 虛擬硬碟的儲存資源成功後，便可以在 HCI 超融合叢集內，不同的 HCI 節點主機之間進行各種資源的線上遷移。
圖 3、Azure Stack HCI 超融合儲存基礎架構示意圖
了解 VM 虛擬主機存取 HCI 超融合叢集的儲存資源方式後，接著進一步了解 Kubernetes 叢集中，擔任 Worker 角色的節點主機（VM 虛擬主機）如何掛載儲存資源，並透過 Kubernetes 叢集調度機制整合 CSI 容器儲存介面，提供儲存資源給予 Pod 內的容器使用（如圖 4 所示）。下列為 Kubernetes 叢集調度 HCI 超融合叢集儲存資源，掛載後給予 Pod 和容器使用的步驟：
7.在 HCI 超融合叢集中，運作的 Kubernetes Controller 主機接收到儲存請求，例如，調度和部署新的Pod。
8. Kubernetes Controller 主機將接收到的儲存請求，轉送至 Kubernetes Worker 節點主機中的「msvhd CSI」驅動程式，這個 msvhd CSI 驅動程式在先前部署 AKS 容器服務時，系統便會自動為 Kubernetes Worker 節點主機完成安裝。
9. Kubernetes Worker 節點主機透過 msvhd CSI 驅動程式，向底層 HCI 超融合叢集中所有的 HCI 節點主機送出儲存資源請求。
10.接收儲存資源請求的 HCI 節點主機，建立 VHDX 虛擬硬碟並執行附加和掛載的動作，提供給剛才提出儲存資源請求的 Kubernetes Worker 節點主機。
11. Kubernetes Worker 節點主機，感知到附加的 VHDX 虛擬硬碟之後進行儲存裝置格式化，倘若為 Linux Worker 節點主機便採用 EXT4 檔案系統進行格式化，若是 Windows Worker 節點主機則採用 NTFS 檔案系統進行格式化。
12.儲存裝置格式化程序完成後，Kubernetes Worker 節點主機將獲得的儲存資源掛載至 Pod，以便 Pod 內部運作的容器得以使用掛載完成的儲存資源。
圖 4、Kubernetes Worker 節點主機，附加和掛載 HCI 超融合叢集儲存資源示意圖
實戰 – 部署 AKS on Azure Stack HCI
在 Azure 公有雲環境中使用 AKS 容器服務時，雖然管理人員可以透過 Azure Portal 操作介面，管理 Kubernetes 的「控制平面」（Control Plane）基礎架構，但是控制平面和容器化應用程式的底層基礎架構，則是運作在 Azure 公有雲環境所管理的 VM 虛擬主機中運作，管理人員並無法碰觸和進行管理（如圖 5 所示）。
圖 5、在 Azure 公有雲環境中，使用 AKS 容器服務運作架構示意圖
圖 6、在 HCI 超融合叢集中，部署 AKS 容器服務運作架構示意圖
安裝 Azure Kubernetes Service 擴充模組
在本文實作環境中，總共建立四台主機，一台主機採用 Windows Server 2019 作業系統，擔任 DC 網域控制站並建立名稱為「hci.weithenn.org」的網域環境，並且啟動 DNS 及 DHCP 伺服器的角色，另一台主機採用 Windows 10 Enterprise 20H2 版本，擔任 Windows Admin Center 管理平台角色，其它二台主機採用最新版本的 Azure Stack HCI 20H2 雲端作業系統，擔任 HCI 超融合叢集中節點主機角色。
在 WAC（Windows Admin Center）管理主機的部份，完成基本的系統組態設定後加入「hci.weithenn.org」網域環境，並安裝最新版本「Windows Admin Center version 2009」。但是，登入 WAC 管理介面後，管理人員會發現在可安裝擴充模組的頁面中，並沒有「Azure Kubernetes Service」項目可供點選安裝？
請注意! 必須採用 Windows 10 擔任 WAC 管理平台角色，因為採用 Windows Server 2019 安裝 WAC 之後，屆時將會因為採用伺服器運作的 WAC Gateway 模式，導致部署 AKS 容器服務失敗的情況。
出現這個情況的主要原因在於，落地 HCI 超融合叢集的 AKS 容器服務處於公開預覽狀態，所以管理人員必須先至 AKS on Azure Stack HCI 預覽註冊 頁面，完成註冊的動作後下載包括「.nupkg」的檔案，也就是適用於 WAC 擴充模組的 NuGet 套件，然後將 .nupkg 檔案儲存於 WAC 管理主機或 SMB 共用資料夾中。本文實作環境將下載後的 .nupkg 檔案，儲存於 WAC 管理主機的「C:\AKS-on-HCI-Lab」資料夾內。
接著，在 WAC 管理介面中依序點選「Settings > Gateway > Extensions > Feeds > Add」項目，在彈出新增套件視窗路徑中貼上剛才儲存 .nupkg 的檔案路徑，順利載入新增的 NuGet 套件路徑後，回到可安裝擴充模組頁面中即可看到「Azure Kubernetes Service」項目，請按下 Install 鈕進行 AKS 容器服務擴充模組的安裝程序（如圖 7 所示）。
圖 7、安裝適用 WAC NuGet 套件中的 AKS 容器服務擴充模組
部署 Azure Kubernetes Service 管理叢集
當 AKS 容器服務擴充模組安裝完成後，回到 HCI 超融合叢集管理介面中，將會看到多出 Azure Kubernetes Service 項目。值得注意的是，在開始部署 Azure Kubernetes Service 管理叢集之前，必須確保已經將 HCI 超融合叢集，註冊並連結至 Azure 公有雲環境（如圖 8 所示），否則稍後將無法順利部署 Azure Kubernetes Service 管理叢集。
圖 8、確認 HCI 超融合叢集已經註冊和連結至 Azure 公有雲環境
圖 9、準備部署 Azure Kubernetes Service 管理主機
在部署階段 2 系統檢查頁面中，請鍵入 HCI 超融合叢集的管理者帳號和密碼，系統會預先檢查 WAC 管理平台，是否已經正確註冊和連結至 Azure 公有雲環境，同時檢查 WAC 管理主機的儲存空間是否足夠存放，稍後下載 Azure Kubernetes Service 管理叢集的安裝映像檔，最後檢查 HCI 超融合叢集的系統組態設定，包括記憶體資源和 CSV 叢集共用磁碟區儲存空間是否足夠……等（如圖 10 所示）。
圖 10、檢查 WAC 管理主機和 HCI 超融合叢集系統組態設定
在部署階段 3 主機組態設定頁面中，請組態設定 AKS 容器服務的管理叢集名稱，選擇存放 AKS 管理叢集主機的 CSV 叢集共用磁碟區，以及所要採用的 vSwitch 虛擬網路交換器，最後則是負載平衡器的組態設定（如圖 11 所示）。
請注意，屆時運作和承載容器的 Linux 及 Windows Workers 節點主機，也會採用此步驟中所選擇的 vSwitch 虛擬網路交換器。
圖 11、組態設定 AKS 管理主機的叢集名稱和 vSwitch 虛擬網路交換器
在部署階段 4 Azure 註冊頁面中，系統將會彈出視窗請管理人員鍵入準備使用的 Azure 訂閱帳戶，通過身份驗證程序後，便會顯示該 Azure 訂閱帳戶所能使用的 Azure 訂閱項目（如圖 12 所示）。
圖 12、鍵入使用的 Azure 訂閱帳戶並選擇欲採用的 Azure 訂閱項目
在部署階段 5 檢視和建立頁面中，再次檢視相關組態設定內容確認無誤後，按下 Next 鈕便開始執行部署 Azure Kubernetes Service 管理主機的動作。在本文實作環境中，部署 AKS 管理叢集和相關主機的動作，花費 56 分鐘才完成（如圖 13 所示）。
圖 13、成功部署 Azure Kubernetes Service 管理叢集和相關主機
現在，管理人員可以看到 AKS 管理叢集的相關概要資訊，例如，本文採用的 Kubernetes 版本為「v1.18.8」。值得注意的是，切換到「Compute > Virtual machines」項目，管理人員將會看到系統已經自動建立二台 VM 虛擬主機，並且這二台 VM 虛擬主機名稱中關鍵字分別為「Control-Plane」和「Load Balancer」，這二台 VM 虛擬主機便是負責 AKS 管理叢集中控制平面的部份。
此外，當管理人員查看這二台 VM 虛擬主機的內容時，將會發現作業系統名稱為「Common Base Linux Mariner」（如圖 14 所示）。簡單來說，它是一個開放源始碼的 Linux 發行版本，剛才部署 AKS 容器服務時，系統自動執行下載和部署的動作，有興趣更深入了解的管理人員請參考 GitHub – Microsoft/CBL-Mariner: Linux OS for Azure 1P services and edge appliances 內容。
圖 14、負責 AKS 容器服務控制平面機制的 VM 虛擬主機，採用 Common Base Linux Mariner 作業系統
部署 Kubernetes 叢集
順利部署 AKS 容器服務管理叢集後，便可以接著部署 Kubernetes 叢集。管理人員可以在 WAC 首頁依序點選「Add > Kubernetes Cluster（Preview）> Create new」項目，或是在剛才 AKS 容器服務概要資訊頁面中，依序點選「Kubernetes Clulsters > Add Cluster」項目即可。
首先，在部署階段 1 先決條件頁面中，可以看到系統提醒管理人員部署 Kubernetes 叢集注意事項。在部署階段 2 基本設定頁面中，請管理人員鍵入部署 Kubernetes 叢集的相關組態設定，例如，是否與 Azure Arc 進行整合、Kubernetes 叢集名稱……等（如圖 15 所示）。值得注意的是，在尚未通過 AKS 容器管理叢集身份驗證程序前，將會發現無法選擇 Kubernetes 叢集主要管理主機規格，必須待通過身份驗證程序後，才能調整 Kubernetes 叢集主要管理主機規格大小。
在公開預覽期間，雖然無法調整 Kubernetes 叢集管理節點主機數量，但管理人員可以調整管理主機的規格大小。
圖 15、鍵入部署 Kubernetes 叢集的相關組態設定
在部署階段 3 節點主機集區頁面中，管理人員可以組態設定新增 Windows 或 Linux 節點主機數量。在部署階段 4 網路組態頁面中，管理人員可以定義 Kubernetes 叢集中，Pod 和 Kubernetes 叢集服務的 IP 位址範圍，以及負載平衡器、網路原則、HTTP 應用程式路由……等資訊（如圖 16 所示）。
在 AKS 容器服務公開預覽期間，僅能新增一台 Windows 節點主機和一台 Linux 節點主機。
圖 16、組態設定 Kubernetes 叢集虛擬網路環境
在部署階段 5 整合儲存資源頁面中，系統將顯示 Kubernetes 叢集 CSI 容器儲存介面所要使用的儲存資源，以及持續性磁碟區的種類為固定或動態。在部署階段 6 檢視和建立頁面中，請管理人員再次檢視組態設定內容，確認無誤後按下 Create 鈕立即執行部署 Kubernetes 叢集的動作，在本文實作環境中，系統花費 9 分鐘時間順利部署 Kubernetes 叢集（如圖 17 所示）。
圖 17、順利部署 Kubernetes 叢集
現在，管理人員可以在 AKS 概要資訊頁面中，看到剛才部署的 Kubernetes 叢集健康情況以及採用的版本。同時，切換到「Compute > Virtual machines」項目，管理人員將會看到系統已經自動部署二台 VM 虛擬主機，並且這二台 VM 虛擬主機名稱中關鍵字也有「Control-Plane」和「Load Balancer」，這二台 VM 虛擬主機便是負責剛才部署 Kubernetes 叢集中控制平面的部份。
此外，管理人員也可以在 PowerShell 視窗中使用「kubectl get」指令，查詢 Kubernetes 管理叢集的系統相關資訊（如圖 18 所示）。
圖 18、查詢 Kubernetes 管理叢集的系統相關資訊
部署 Linux 節點主機
由於，剛才在部署 Kubernetes 叢集時為了加速部署速度，並沒有選擇額外部署 Linux 或 Windows節點主機。因此，當管理人員透過「Get-AksHciCluster」指令，查詢 Kubernetes 叢集時，可以發現僅部署控制平台，尚未部署 Linux 或 Windows 節點主機（如圖 19 所示）。
圖 19、查詢 Kubernetes 叢集系統主機資訊
管理人員透過 PowerShell 指令「Set-AksHciClusterNodeCount」，搭配參數「-linuxNodeCount 1」，指定 Kubernetes 叢集立即部署一台 Linux 節點主機（如圖 20 所示）。部署作業完成後，再次透過「Get-AksHciCluster」指令，即可查詢到 Kubernetes 叢集已經部署一台 Linux 節點主機。
圖 20、指定 Kubernetes 叢集立即部署一台 Linux 節點主機
部署 Linux 容器和應用程式
現在，管理人員可以透過 YAML 檔定義運作指定的容器映像檔。在本文實作環境中，將部署 Azure 投票應用程式（azure-vote.yaml），這個 Azure 投票應用程式的前端介面採用 Python / Flask 技術，而資料元件的部份則採用 Redis，有興趣深入了解的管理人員請參考 GitHub - Azure-Samples/azure-voting-app-redis: Azure voting app used in docs. 內容。
完成「http://azure-vote.yaml」的 YAML 檔案內容後，執行「kubectl apply -f azure-vote.yaml」指令，立即部署「azure-vote-front」和「azure-vote-back」應用服務至 Kubernetes 叢集（如圖 21 所示）。部署完成後，可以查看 Kubernetes 叢集的 deployment、pods、service 狀態，其中「EXTERNAL-IP」欄位中的 IP 位址，便是透過使用者存取 Azure 投票應用程式的 IP 位址。
請注意! 剛開始執行部署作業時，EXTERNAL-IP 欄位將為「pending」狀態，待部署完成且正確連接負載平衡器後，系統才會顯示可供使用者存取應用程式的 IP 位址。
圖 21、部署 Azure 投票應用程式至 Kubernetes 叢集
現在，使用者可以透過瀏覽器存取 Azure 投票應用程式，本文實作環境 IP 位址為「10.10.75.104」（如圖 22 所示），使用者可以隨意投票或按下 Reset 鈕清除投票結果。
圖 22、使用者透過瀏覽器存取 Azure 投票應用程式
調整 Pod 運作規模
順利部署 Azure 投票應用程式後，管理人員可以隨時依照使用者存取和 Pod 工作負載情況，隨時線上調整「azure-vote-front」和「azure-vote-back」服務的運作規模。
舉例來說，目前僅分別部署一個 Pod 來運作 azure-vote-front 和 azure-vote-back 工作負載，管理人員可以搭配參數「scale --replicas=5」，將指定的 Pod 數量從原本的「1 個」提升數量為「5 個」，也可以透過參數「scale --replicas=3」，將指定的 Pod 數量從提升後的「5 個」降低數量為「3 個」（如圖 23 所示）。
圖 23、調整 Kubernetes 叢集內 Pod 運作規模
結語
透過本文的深入剖析及實戰演練，管理人員只要透過 WAC 管理平台，即可在企業和組織地端資料中心內的 Azure Stack HCI 超融合叢集中，輕鬆部署 AKS 容器服務和控制平面基礎架構，以及 Kubernetes 叢集和 Linux 與 Windows 節點主機，達成快速建構和部署 Kubernetes 叢集及容器應用程式的目標。
