容器 Container Kubernetes K8s DevOps

Project Pacific全面啟動 徹底翻新虛擬主機管理平台

K8s深度整合vSphere VMware Tanzu全新出擊

2020-03-16
VMware日前發布Tanzu,由Project Pacific來打造全新的vSphere基礎架構平台,讓K8s API直接深度整合到vSphere API,將能夠呼應Ops管理人員以往管理VM虛擬主機的習慣,並滿足Dev開發人員在部署及管理新型態應用容器的工作負載,本文將介紹這個全新平台的特色並實際操作示範。

 

在2018年時,VMware併購由兩位Kubernetes(後續將簡稱為K8s)創辦人Joe Beda和Craig McLuckie創立的Heptio公司,經過幾個月的整合之後,正式在VMworld 2019年度大會上推出名為「VMware Tanzu」的解決方案。

過去IT管理人員對於VMware解決方案的認知,是建構在vSphere ESXi虛擬化平台中,相關服務皆圍繞著VM虛擬主機為中心。然而,現代化的應用程式和服務已經改採「容器」(Container),搭配容器調度管理平台K8s為主,搭配運作在VM虛擬主機內傳統的應用程式,如圖1所示。在Tanzu解決方案中,最亮眼的運作元件之一應屬「Project Pacific」。簡單來說,Project Pacific便是將vSphere ESXi虛擬化平台,與K8s容器調度平台深度融合在一起,如圖2所示,並針對企業和組織提供下列優點:

圖1  傳統應用服務和現代化分佈式應用服務示意圖。(圖片來源:VMware官網 – Introducing Project Pacific)
圖2  Project Pacific新一代vSphere管理平台運作架構示意圖。(圖片來源:VMware vSphere Blog - Introducing Project Pacific)

‧vSphere原生支援K8s:在Project Pacific中,將K8s直接嵌入至vSphere的控制平面中,讓管理人員可以統一管理VM虛擬主機和容器的各項資源,例如運算、儲存、網路等等,並且管理人員無須更換管理工具和操作習慣,透過原有的vSphere HTML 5 Client管理工具,即可查看和管理K8s物件,例如Pod、Namespace、Container等等。

‧應用程式為管理中心:過去管理中心以VM虛擬主機為主,現在管理人員可以直接透過vCenter Server管理平台,針對K8s叢集直接管理所有的容器和VM虛擬主機及企業進階功能,包含vSphere HA、vSphere DRS、vSphere vMotion等等,讓企業營運服務中的應用程式正式成為管理中心。

‧加速DevOps步調:在現有的IT管理工具中,Ops管理人員負責建構和管理K8s叢集,而Dev開發人員則使用K8s API存取SDDC軟體定義基礎架構。現在Dev和Ops可以透過vSphere看到相同的運作環境並進行管理和部署作業,加速協同運作。

以下將針對在VMworld 2019年度大會上發佈的VMware Tanzu管理平台中,由Project Pacific打造的全新下一代vSphere基礎架構平台,也就是將K8s API直接深度整合到vSphere API當中,讓企業組織內的Dev開發人員可以透過K8s API管理容器,而Ops管理人員能夠像過去管理vSphere ESXi中VM虛擬主機的方式,來直接管理K8s叢集和容器。

深入剖析Project Pacific特色

Project Pacific所具備的特色功能,可分成以下三方面來加以說明。

K8s即平台(K8s as a Platform)

過去無論是開發人員或管理人員對於K8s調度管理平台的印象,可能僅能針對「容器」(Container)進行負載平衡和管理的動作。

而Project Pacific則是將K8s打造成可以調度「任何工作負載」的管理平台,並且直接原生融入至原有的vSphere虛擬化基礎運作架構中。

現在開發人員可以採用YAML檔案,透過K8s API管理和調度容器的生命週期,而IT管理人員也可採用YAML檔案,透過vSphere API管理和調度VM虛擬主機的生命週期,如圖3所示。因此,企業組織能夠採用相同的標準作業流程,來管理企業營運服務的生命週期,同時加速整體數位轉型的步調。

圖3  透過K8s API和vSphere API同時管理容器和VM虛擬主機運作架構示意圖。(圖片來源:VMware vSphere Blog - Project Pacific - Technical Overview)

以應用程式為中心

在舊有的vSphere虛擬化基礎架構中,Ops管理人員所著重的是「VM虛擬主機」,舉例來說,當運作VM虛擬主機底層x86硬體伺服器需要進行計畫性維運時,可以透過vSphere vMotion線上遷移機制,讓VM虛擬主機和內部運作的營運服務能夠不中斷地遷移且持續運作,即便發生非計畫性故障事件時,也可透過vSphere HA或FT高可用性機制,讓VM虛擬主機僅發生短暫的停機時間或無縫接手服務,甚至當VM虛擬主機工作負載異常暴增時,也可以針對VM虛擬主機使用的硬體資源進行限制的動作等等。

現在可透過K8s運作架構中大家所熟知的「Namespace」機制,來解決無法以應用程式為中心的困擾。簡單來說,管理人員可以將Namespace想像成一個資料夾,它可以承載各式各項的資源,例如容器、VM虛擬主機、vDisk儲存資源、加密機制、HA高可用性機制等等。

如圖4所示,在一個Namespace當中同時運作著傳統應用程式的VM虛擬主機,以及不適合容器化由VM虛擬主機組成的資料庫叢集,搭配適合容器運作架構的現代化應用程式,以及無伺服器架構的Serverless服務,而管理人員能夠輕鬆地針對整個Namespace進行管控,例如硬體資源的使用率、網路資料傳輸安全性、工作負載可用性、機敏資料存取管控等等。

圖4  以Namespace為單位進行工作負載管控作業示意圖。(圖片來源:VMware vSphere Blog - Project Pacific - Technical Overview)

Supervisor - 新世代叢集架構

對管理人員來說,過去在vSphere基礎運作架構中,便是透過ESXi的「Hypervisor」機制,將底層x86伺服器硬體資源抽象化之後,提供給上層運作的VM虛擬主機使用,並且透過建立vSphere叢集,將底層硬體資源進行匯整。

而目前在Project Pacific運作架構中,將採用新世代叢集運作架構「Supervisor Cluster」。簡單來說,在傳統的K8s叢集中,節點主機無論是實體伺服器或VM虛擬主機皆採用Linux主機,並且管理人員透過「Kubelet」進行管理的動作,而新世代叢集Supervisor Cluster的節點主機則是ESXi,並且原生整合至ESXi之後以「Spherelet」進行管理的動作。

在Supervisor Cluster上運作的Pod都會在各自「獨立」的VM虛擬主機內運作,這並非傳統的VM虛擬主機,而是經過最佳化調校並包括Linux核心,最適合容器環境運作的半虛擬化VM虛擬主機稱之為「CRX」,如圖5所示。因此,最佳化後的CRX虛擬主機能夠在「100毫秒(ms)」之內啟動Pod,並在單台ESXi主機上可以運作超過1,000個Pods,整個Supervisor Cluster最多可運作多達8,000個Pods,同時根據VMware官方內部測試結果顯示,在CRX虛擬主機Pod內運作的Java比傳統Pod傳輸量高出30%,相較於裸機的Linux主機也快8%。

圖5  針對容器工作負載最佳化的CRX虛擬主機運作示意圖。(圖片來源:VMware vSphere Blog - Project Pacific - Technical Overview)

此外,當企業需要在Supervisor Cluster中建構Guest Cluster時,如圖6所示,也就是在Linux VM虛擬主機中建構傳統K8s Cluster時,也能夠透過Cluster API與上層Supervisor Cluster進行互動來達到管理一致性的目的。

圖6  Supervisor Cluster上層運作的Guest Cluster透過Cluster API進行互動的架構示意圖。(圖片來源:VMware vSphere Blog - Project Pacific - Technical Overview)

實作演練Project Pacific運作

雖然目前Project Pacific仍處於技術預覽階段,但管理和開發人員仍然可以透過VMware HOL(Hands-on-Labs)實作。 接下來,將實作演練如何建構Supervisor Cluster,並且部署多個Nginx容器和網路負載平衡機制。

Ops管理人員建構Supervisor Cluster

先登入vCenter Server的vSphere HTML 5 Client管理介面,依序點選「Menu > Workload Platform」。

然後,在Getting started with Workload Platform頁面最下方按下〔I'm Ready〕按鈕,表示管理人員同意在目前的vSphere Cluster中啟用並轉換為新世代Supervisor Cluster運作架構。

這個時候,系統將會彈出Select a Cluster視窗,選擇要轉換成Supervisor Cluster運作架構的vSphere Cluster後,如圖7所示,按下〔OK〕按鈕進入下一個組態設定。

圖7  選擇要轉換成新世代Supervisor Cluster運作架構的vSphere Cluster。

接著,必須組態設定轉換後的Supervisor Cluster,管理人員可以依據工作負載的情況,選擇適合的叢集大小,本文實作環境選擇「Tiny」規模大小,可運作約1,000 Pods,如圖8所示。

圖8  選擇Supervisor Cluster運作規模大小。

在Network組態設定頁面中,管理人員必須為「控制平面」(Control Plane)組態設定網路資訊。首先,必須為Supervisor Cluster架構中的每台ESXi成員主機,組態設定「管理網路」(Management Network)資訊,以便屆時vCenter Server管理平台能夠管控每台ESXi成員主機。

然後,組態設定「名稱空間網路」(Namespace Network)資訊,如圖9所示,以便屆時Supervisor Cluster架構中的每台ESXi成員主機和Pods,能夠透過K8s API進行互動和溝通,在本文實作環境中採用NSX Distributed Switch和Edge,並且主要節點將會配置VIPs(Virtual IP),以便屆時進行網路流量負載平衡。

圖9  組態設定Supervisor Cluster中管理網路和名稱空間網路資訊。

在Storage組態設定頁面中,由於屆時運作容器的容器映像檔,會由整合至內部的Harbor Container Registry提供,而非讓ESXi節點主機至網際網路上公開的Container Registry下載容器映像檔,所以管理人員必須選擇容器映像檔所要使用的儲存資源。而在Review and Confirm頁面中,管理人員再次檢視Supervisor Cluster的組態設定內容是否正確,確認無誤後按下〔Finish〕按鈕,如圖10所示,當下方Recent Tasks工作項目欄位中,組態設定Supervisor Cluster的工作任務執行完畢,在Workload Platform頁面中的〔Clusters〕頁籤內,便會出現已經轉換成Supervisor Cluster的vSphere Cluster。

圖10  再次檢視Supervisor Cluster運作環境組態設定是否正確。

此時,回到Hosts and Clusters頁面中,將會看到系統自動建立一個名稱為「Namespaces」的「資源集區」(Resource Pool),點選並進入資源集區當中,將會發現系統已經自動啟動和運作一台VM虛擬主機,這台便是擔任Kubernetes MasterAPI工作任務的VM虛擬主機,如圖11所示。

圖11  成功部署Supervisor Cluster並啟動Kubernetes MasterAPI VM虛擬主機。

至此,已經成功部署Supervisor Cluster,接著將在Supervisor Cluster內建立一個新的名稱空間,這個名稱空間便是K8s的核心運作元件,也就是開發人員所熟悉和使用的名稱空間。在vSphere HTML 5 Client管理介面中,依序點選「Menu > Workload Platform > Namespaces > Create Namespace」項目,在彈出的Create Namespace視窗內,選擇準備建立名稱空間的vSphere資料中心和叢集,然後在Name欄位內鍵入所要新增的名稱空間(本文實作環境為hol),最後按下〔Create〕按鈕即可。

當新增名稱空間的工作任務完成後,依序點選「Host and Clusters > Namespaces > hol」項目後,便可以看到新增用於開發人員用途的K8s名稱空間概要資訊,如圖12所示。

圖12  新增用於開發人員用途的K8s名稱空間概要資訊。

現在將針對剛才所新增的「hol」K8s名稱空間,指派開發團隊中的「Fred」使用者帳號具備編輯權限,而在使用者帳號身分驗證的部分,則採用原有的vSphere SSO(Single Sign-On)身分驗證機制。

在hol K8s名稱空間中,依序點選「Summary > Permissions > Add Permissions」項目,在彈出的Add Permissions視窗中依照運作環境需求進行設定。首先,在Identity source中選擇採用的vSphere SSO網域名稱,在User/Group欄位中鍵入欲指派的使用者帳號或群組(本文實作為Fred),最後在Role欄位中指派權限(本文實作為Can edit)即可。目前,在hol K8s名稱空間中,僅「Fred」這個使用者帳號能夠進行存取和編輯,其他使用者帳號和群組皆無法存取。

因此,管理人員透過建立「儲存原則」(Storage Policy),然後與K8s名稱空間進行關聯,便可以達到K8s名稱空間使用不同的儲存資源或限制儲存資源使用率的目的。

接著,在hol K8s名稱空間中,依序點選「Summary > Storage > Add Storage」項目,在彈出的Edit Storage Poilcies視窗中,選擇所要套用的儲存原則(本文實作為high-performance-ssd),然後按下〔OK〕按鈕,便可以看到high-performance-ssd儲存原則已經與hol K8s名稱空間進行關聯,如圖13所示。此時系統將會在指定的K8s名稱空間儲存資源中,建立K8s儲存用途的Persistent Volumes。

圖13  指派使用者帳號和群組針對hol K8s名稱空間的存取權限,並與指定的儲存原則進行關聯。

管理人員也可針對hol K8s名稱空間的硬體資源使用率進行限制,依序點選「Configure > Resource Limits > Edit」項目,在彈出的Resource Limits視窗內,針對hol K8s名稱空間的硬體資源進行限制,例如限制僅能使用3,000MHz和1,000MB的CPU和Memory運算資源,在儲存資源的部分僅能使用2,000MB,如圖14所示。

圖14  組態設定限制hol K8s名稱空間的硬體資源使用率。

Supervisor Cluster部署和管理容器

當vSphere系統管理人員建構完成Supervisor Cluster之後,可以開始專注在開發人員的使用層面上,開始使用vSphere K8s Cluster進行部署和管理容器的動作。

首先,將為開發人員的Windows或Linux或Mac開發主機安裝K8s CLI指令工具。在vSphere HTML 5 Client管理介面中,依序點選「Namespaces > hol > Summary > Status > Link to CLI Tools > Open」,然後選擇安裝的作業系統類型,即可從vCenter Server下載K8s CLI指令工具。

在本文實作環境中,將在Ubuntu虛擬主機中,透過wget指令進行下載,然後搭配unzip指令進行解壓縮的動作,如圖15所示。

圖15  在Ubuntu虛擬主機中下載和解壓縮K8s CLI指令工具。

現在開發人員可以透過K8s CLI指令工具連線至Supervisor Cluster控制平面,也就是vCenter Server,鍵入「kubectl vsphere login」指令,並指定vCenter Server IP位址「--server=192.168.124.1」,以及登入的使用者帳號「--vsphere-username fred@vsphere.local」。

成功通過身分驗證程序後,執行「kubectl config get-contexts」指令,查詢開發人員帳號Fred能夠存取的名稱空間有哪些。再執行「kubectl config use-context hol」指令,將使用的名稱空間指向至「hol」。最後執行「kubectl get all」指令,查詢hol名稱空間內運作的工作負載,由於hol名稱空間內尚未運作任何容器,所以會顯示為「No resources found」,如圖16所示。

圖16  開發人員透過kubectl指令與Supervisor Cluster控制平面建立連線。

由於在建立Supervisor Cluster時已經指派和關聯儲存資源,現在便可以透過YAML檔案,執行建立K8s Persistent Volume的動作。首先,查看「nginx-claim.yaml」檔案內容,然後執行「kubectl apply -f nginx-claim.yaml」指令建立,再執行「kubectl get pvc」確認Persistent Volume是否建立完成,如圖17所示。

圖17  建立K8s Persistent Volume儲存資源。

至此,就能夠執行部署Pod和容器的動作。首先,執行「cat nginx-pers.yaml」指令,查看部署Pod和容器的YAML檔案內容,確認無誤後,輸入「kubectl apply -f nginx-pers.yaml」指令,執行部署Pod和Nginx容器的動作。然後,執行「kubectl get all」指令以確認Pod和Nginx容器是否部署成功,如圖18所示。

圖18  執行和確認Pod和Nginx容器是否部署成功。

開發人員可以使用相同的容器管理經驗,執行「kubectl exec -it」指令,配合Nginx容器名稱,即可進入容器內部進行互動操作,如圖19所示。此時,回到vSphere HTML 5 Client管理介面,再次確認Pod和Nginx容器是否都已經部署成功,並且觀察是否使用Persistent Volume儲存資源。

圖19  進入容器內部進行互動操作。

在管理介面中,依序點選「Menu > Hosts and Clusters > Namespaces > hol」項目,就會看到一台以「nginx」開頭為命名的特殊VM虛擬主機圖示,裡頭便運作剛才所部署的Pod和Nginx容器。

點選該台VM虛擬主機後,再點選〔Monitor〕頁籤便可以看到有關於這個Pod和容器的K8s Events,接著點選「Storage > Persistet Volume > Volume Name > Details > Basic」項目,即可看到哪一台CRX虛擬主機,使用哪個Datastore和Persistent Volume儲存資源,並且與哪一個儲存原則互相關聯,如圖20所示。

圖20  查詢部署的Nginx容器使用的儲存資源詳細資訊。

最後,部署具備流量負載平衡機制的Nginx網頁伺服器運作環境。首先,透過YAML檔案內的「replicas : 3」表示即將部署3個Nginx容器。先執行「kubectl apply -f nginx-lbsvc.yaml」進行部署動作,再輸入「kubectl get all」命令確認已經部署3個Nginx容器,如圖21所示。

圖21  部署3個Nginx容器,並準備建立網路流量負載平衡機制。

執行「kubectl get svc -o wide」,確認是否部署K8s負載平衡機制,稍待一小段時間後,即可看到「External-IP」欄位出現負載平衡IP位址,如圖22所示。

圖22  確認Kubernetes負載平衡機制是否部署成功。

此時,便可以開啟瀏覽器分頁,並在URL鍵入剛才得到的負載平衡IP位址。但是,可能會無法存取Nginx頁面資訊,主要原因在於,預設情況下,K8s Namespace Ingress會「Block」所有網路流量所導致。

可以查看一下enable-policy.yaml檔案內容為「allow-all」,執行「kubectl apply -f enable-policy.yaml」來允許K8s Namespace Ingress網路流量通過,如圖23所示。

圖23  允許K8s Namespace Ingress網路流量通過。

事實上,當開發人員允許K8s Namespace Ingress網路流量通過時,系統就會在NSX Distributed Firewall防火牆規則中,自動「新增」Namespace Ingress網路流量允許規則,如圖24所示。此時,再次回到瀏覽器分頁並且在URL欄位鍵入Nginx容器的負載平衡IP位址,就能夠正確存取Nginx首頁了。

圖24  系統自動新增Namespace Ingress網路流量允許規則。

結語

透過本文的深入剖析和實作演練後,將會發現新一代的vSphere管理平台Project Pacific,能夠提供Ops管理人員過往管理VM虛擬主機的習慣,也同時滿足Dev開發人員在部署和管理新型態應用容器的工作負載,幫助企業和組織加速前往DevOps的步調。

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

 


追蹤我們Featrue us

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

我知道了!