Azure Stack HCI 超融合基礎架構 Kubernetes 容器 VM

移植Azure公有雲AKS容器服務 落地到HCI超融合叢集環境

WAC管理混合雲工作負載 輕鬆部署K8s叢集及容器

2021-04-12
透過本文的實戰演練,管理人員只要使用WAC管理平台,即可在企業地端資料中心的Azure Stack HCI超融合叢集中,輕鬆部署AKS容器服務和控制平面基礎架構,以及Kubernetes叢集和Linux與Windows節點主機,達成快速建構和部署Kubernetes叢集及容器應用程式的目標。

 

隨著新一代的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容器服務示意圖。 (圖片來源:Microsoft Tech Community - AKS on AzureStack HCI now in Public Preview)

企業和組織的管理人員,除了方便將營運服務的容器化工作負載達成一致性之外,打包客製化好的Linux或Windows容器映像檔,無須進行任何更改即可隨時部署於Azure公有雲環境,以及地端資料中心內建構的HCI超融合叢集環境中,達到真正混合雲部署和管理工作負載的目的。

管理人員可以透過PowerShell指令進行管理,也可以採用WAC(Windows Admin Center)管理平台,達到部署和管理AKS容器服務和容器工作負載的目的。當管理人員需要建立Kubernetes叢集時,只要在WAC管理介面中按下〔Add〕新增按鈕,即可看到支援部署Kubernetes叢集的選項,如圖2所示。

圖2  透過WAC管理平台部署Kubernetes叢集。

AKS on Azure Stack HCI儲存架構

在Kubernetes叢集運作架構中,管理人員已經知道「Pod」是最小的工作負載運算資源單位,每個Pod可以包含一個或多個容器化的應用程式,而「持續性磁碟區」(Persistent Volumes)則是Kubernetes叢集中,容器使用儲存資源的基本單位,當Pod裡運作的容器需要儲存資源時,Kubernetes叢集便會執行調度任務讓容器存取持續性磁碟區儲存資源。

事實上,為了達成支援各類儲存供應商,將儲存資源提供給Kubernetes叢集中的容器使用,在Kubernetes叢集中提供了「容器儲存介面」(Container Storage Interface,CSI)機制,以便儲存供應商能夠撰寫各類CSI驅動程式,進而讓Kubernetes叢集可以透過CSI機制存取外部儲存資源。舉例來說,在Azure公有雲環境的AKS容器服務中,當Kubernetes叢集內的容器需要存取儲存資源時,AKS容器服務的控制平台便會自動安裝「azureDisk」和「azureFile」這兩個CSI驅動程式,其中azureDisk用於存取Azure Disks,而azureFile則可存取Azure Files儲存資源。

在了解AKS容器服務的持續性磁碟區儲存資源之前,先說明Azure Stack HCI超融合儲存基礎架構,如圖3所示,以幫助管理人員逐步了解HCI超融合叢集,如何將高效能高可用性的儲存資源,轉換成為持續性磁碟區儲存資源給容器工作負載使用。下列為傳統VM虛擬主機,使用HCI超融合叢集儲存資源的步驟:

圖3  Azure Stack HCI超融合儲存基礎架構示意圖。 (圖片來源:Azure Stack Blog - Deep dive into Azure Kubernetes Service on Azure Stack 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節點主機之間進行各種資源的線上遷移。

了解VM虛擬主機存取HCI超融合叢集的儲存資源方式後,接著進一步了解Kubernetes叢集中,擔任Worker角色的節點主機(VM虛擬主機)如何掛載儲存資源,並透過Kubernetes叢集調度機制整合CSI容器儲存介面,提供儲存資源給予Pod內的容器使用,如圖4所示。下列為Kubernetes叢集調度HCI超融合叢集儲存資源,掛載後給予Pod和容器使用的步驟:

圖4  Kubernetes Worker節點主機附加和掛載HCI超融合叢集儲存資源示意圖。 (圖片來源:Azure Stack Blog - Deep dive into Azure Kubernetes Service on Azure Stack HCI)

1. 在HCI超融合叢集中,運作的Kubernetes Controller主機接收到儲存請求,例如調度和部署新的Pod。

2. Kubernetes Controller主機將接收到的儲存請求,轉送至Kubernetes Worker節點主機中的「msvhd CSI」驅動程式,這個msvhd CSI驅動程式在先前部署AKS容器服務時,系統便會自動為Kubernetes Worker節點主機完成安裝。

3. Kubernetes Worker節點主機透過msvhd CSI驅動程式,向底層HCI超融合叢集中所有的HCI節點主機送出儲存資源請求。

4. 接收儲存資源請求的HCI節點主機,建立VHDX虛擬硬碟並執行附加和掛載的動作,提供給剛才提出儲存資源請求的Kubernetes Worker節點主機。

5. Kubernetes Worker節點主機,感知到附加的VHDX虛擬硬碟之後進行儲存裝置格式化,倘若為Linux Worker節點主機,便採用EXT4檔案系統進行格式化,若是Windows Worker節點主機,則採用NTFS檔案系統進行格式化。

6. 待儲存裝置格式化程序完成之後,Kubernetes Worker節點主機將獲得的儲存資源掛載至Pod,以便Pod內部運作的容器得以使用掛載完成的儲存資源。

AKS on Azure Stack HCI實戰部署

在Azure公有雲環境中使用AKS容器服務時,雖然管理人員可以透過Azure Portal操作介面,來管理Kubernetes的「控制平面」(Control Plane)基礎架構,但是控制平面和容器化應用程式的底層基礎架構,則是運作在Azure公有雲環境所管理的VM虛擬主機中運作,管理人員並無法碰觸和進行管理,如圖5所示。

圖5  在Azure公有雲環境中,使用AKS容器服務運作架構示意圖。 (圖片來源:Microsoft Docs - What is Azure Kubernetes Service on Azure Stack HCI ?)

那麼在HCI超融合叢集中運作的AKS容器服務,與Azure公有雲環境中運作的AKS容器服務有何不同?簡單來說,企業必須全面管理整個AKS容器服務基礎架構,包括AKS容器服務的控制平台和容器化應用程式,都會以VM虛擬主機的方式運作在HCI超融合叢集當中,如圖6所示。

圖6  在HCI超融合叢集中,部署AKS容器服務運作架構示意圖。 (圖片來源:Microsoft Docs - What is Azure Kubernetes Service on Azure Stack HCI ?)

安裝Azure Kubernetes Service擴充模組

在本文實作環境中,總共建立四台主機,一台主機採用Windows Server 2019作業系統,擔任DC網域控制站並建立名稱為「hci.weithenn.org」的網域環境,並且啟動DNS和DHCP伺服器的角色,另一台主機採用Windows 10 Enterprise 20H2版本,擔任Windows Admin Center(WAC)管理平台角色,其他兩台主機採用最新版本的Azure Stack HCI 20H2雲端作業系統,擔任HCI超融合叢集中節點主機角色。

在WAC管理主機的部分,完成基本的系統組態設定後加入「hci.weithenn.org」網域環境,並安裝最新版本「Windows Admin Center version 2009」。但是,登入WAC管理介面後,管理人員會發現在可安裝擴充模組的頁面中,並沒有「Azure Kubernetes Service」項目可供點選安裝。

出現這個情況的主要原因在於,落地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公有雲環境。

先點選Azure Kubernetes Service項目,再按下〔Set Up〕按鈕準備部署Azure Kubernetes Service管理叢集。在部署階段1先決條件頁面中,可以看到系統提醒管理人員前置作業相關注意事項,包括確認HCI超融合叢集已經註冊和連結至Azure公有雲環境,以及可用儲存空間和虛擬網路環境等資訊,如圖9所示。

圖9  準備部署Azure Kubernetes Service管理主機。

在部署階段2系統檢查頁面中,鍵入HCI超融合叢集的管理者帳號和密碼,系統會預先檢查WAC管理平台,是否已經正確註冊和連結至Azure公有雲環境,同時檢查WAC管理主機的儲存空間是否足夠存放,稍後下載Azure Kubernetes Service管理叢集的安裝映像檔,最後檢查HCI超融合叢集的系統組態設定,包括記憶體資源和CSV叢集共用磁碟區儲存空間是否足夠等等,如圖10所示。

圖10  檢查WAC管理主機和HCI超融合叢集系統組態設定。

而在部署階段3主機組態設定頁面中,組態設定AKS容器服務的管理叢集名稱,選擇存放AKS管理叢集主機的CSV叢集共用磁碟區,以及所要採用的vSwitch虛擬網路交換器,最後則是負載平衡器的組態設定,如圖11所示。

圖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的內容(https://github.com/microsoft/CBL-Mariner)。

圖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叢集主要管理主機規格大小。

圖15  鍵入部署Kubernetes叢集的相關組態設定。

在部署階段3節點主機集區頁面中,可以組態設定新增Windows或Linux節點主機數量。在部署階段4網路組態頁面中,則能夠定義Kubernetes叢集中,Pod和Kubernetes叢集服務的IP位址範圍,以及負載平衡器、網路原則、HTTP應用程式路由等等資訊,如圖16所示。

圖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.」的內容。

完成「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位址。

圖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運作規模。

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

 


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!