虛擬架構整合容器環境 實踐DevOps工作模式

自從出現了以YAML格式撰寫組態檔的Docker Compose,讓多個容器(Container)所組成的應用服務在Red Hat、Windows等作業系統皆可執行,可說真正實踐了過去Java陣營希望達成的跨平台目標。緊接著Google釋出的Kubernetes(以下簡稱K8s)可用於自動部署、擴展和管理容器化應用程式,使得「Docker+K8s」逐漸成為現代應用開發的主流架構。

只是K8s現階段仍快速地發展中,在實作於企業營運環境時,勢必得解決幾個普遍存在的問題。VMware資深技術顧問何宗憲指出,首要是不容易維運,例如安裝前需要先餵入憑證,安裝Master與Worker節點,完成後再測試,若發現資源不夠,必須得增設主機;或者操作過程中發生系統錯誤狀況,得重新安裝建置。

其次是網路為CoreOS的Flannel服務,架構較為簡單,須仰賴預先配置的IP路由,不具備擴充能力,一旦節點數量較多,路由配置可能多達幾千條規則,往往難以執行調整變更、問題排除等工作;第三是開發者僅關注於容器環境,但維運者在意的安全性、高可用性與擴充性,卻是現階段K8s運行環境的挑戰,因此眾家IT大廠相繼基於自家優勢投入發展,例如VMware、Pivotal、Google聯手推出的PKS(Pivotal Container Service),即著眼於協助解決前述的問題。

BOSH實現開發者隨需選用K8s版本

過去Docker、K8s尚未成為主流時,只有PaaS平台採用容器技術建構不同的專屬應用環境,直到CoreOS貢獻出Flannel工具,是專為K8s所設計的覆蓋網路(Overlay Network),儘管功能性不多,至少當時已可解決Docker於網路層跨多台主機的架構模式。緊接著K8s社群共同制定出容器網路介面(CNI),使得K8s發展日益迅速,相對的,市場上對PaaS關注度則逐漸下滑。

「VMware透過技術合作方式提出PKS之前,其實本就有VIC、Photon Platform與Photon OS等方案,在Dell收購後進行產品線審查,決議停止發展Photon Platform,取而代之的是PKS。」何宗憲說。

就架構面來看,PKS主要是透過BOSH介接到不同雲端平台,讓封裝檔案內的程式碼呼叫運行。BOSH的定義是IaaS操作者,扮演中介軟體的角色,只要K8s部署指定為AWS、GCP、Azure、vSphere、OpenStack等不同雲端供應商介面(CPI),經由BOSH即可執行部署與調度。

「BOSH技術即來自Pivotal,這也是後來Dell整併後,決定保留PKS而非Photon Platform的主因。」何宗憲說。該技術最初起源於Google內部的Borg叢集管理系統,主要負責的五名Google工程師轉職到Pivotal之後發展為BOSH開源專案,期望能夠達到「Borg++」,因此取「r的下一個字母為s,以及g的下一個字母為h」稱之為BOSH。

在Pivotal容器服務環境中,BOSH底層有VMware NSX-T確保安全性,上層運行PKS控制平面包含K8s on BOSH(以前稱為Kubo,現已改名為Cloud Foundry Container Runtime,簡稱CFCR),以及在兩岸三地被廣泛採用的Harbor開源專案,用以存放映像檔倉庫(Repository)。主要目的是藉由BOSH來實現K8s On-demand,也就是容器即服務(CaaS)的概念,不僅可讓開發團隊依照專案需求申請不同版本的K8s技術環境,同時也不會有廠商設計專屬的指令集,直接採用K8s原生的執行方式即可。

自主復原降低IT維運負擔

▲VMware資深技術顧問何宗憲強調,以IaaS為基礎架構Master節點與Worker節點,開發者毋須關注底層環境,容器即服務(CaaS)即可提供不同應用開發所需的運行環境。
執行BOSH部署時,首先要指定雲端供應商介面,其次是Linux虛擬機樣板StemCell佈建,依據YAML檔案配置Master與Worker節點運行的虛擬主機環境。該虛擬主機上的BOSH Release為已經配置完成的Kubo,透過「pks create-cluster」指令,即可自動產生K8s叢集架構,不同開發團隊可藉此產生獨立的運行環境。

「我們的定位較其他廠商不同,更多面向於IT人員,畢竟VMware的操作者並非開發者。就維運的角度來看,更在意的是版本更新、高可用性、安全性等問題,也因此Pivotal已通過美國國防部安全檢查,實際被應用在軍方單位。」何宗憲強調。

假設單一Worker節點故障顯示為紅色,Container仍可正常運行,BOSH會偵測到訊號異常,因為所有的指令都是透過BOSH執行部署,得以掌握所有節點狀態,當訊號遺失時,將執行刪除VMDK、再產生一台虛擬主機掛載到叢集的方式,來實現自主復原(Self-healing)。當然,自主復原實踐的因素還包括底層的SDDC(軟體定義資料中心)架構,可基於實體資源池來彈性配置。

為什麼刪除VMDK還要再增添掛載?他指出,主要是在容器環境中有Persistent Volumes機制,可能有些資料會寫入磁碟區,若全部刪除,資料也會一併消失,因此要先卸載,新增虛擬主機後再把資料附加回來。

「自主復原能力現階段在K8s中不具備,未來恐怕也難以實現。之所以有此論點是因為K8s不會限制部署環境,若為實體主機而非IaaS環境,根本無法達到自我復原。」何宗憲說。

IDC FutureScape在2017年針對全球企業基礎架構預測,容器技術發展到2020年,將至少有70%被部署在虛擬化基礎架構;Gartner年初發布預測也指出,今年(2018)將會有超過60%的容器是運行在虛擬主機之上。

論及Hypervisor技術,仍是VMware最具優勢。何宗憲進一步說明,「確實有另一派的說法是虛擬主機須要佔用3%到5%資源,基於實體機運行的容器環境,較可確保效能。概念上我認為有道理,但是藉此來降低系統中斷風險,更是營運環境關注的重點。在此同時,VMware也會持續以新技術克服Hypervisor耗用效能的問題,例如RDMA。」

以前虛擬網卡,必須由CPU把封包遞送到實體網卡,確實須耗用效能,現在只要網卡支援RDMA驅動程式,虛擬與實體網卡彼此之間可直接傳遞,不須再透過CPU,VMware稱為RoCE(RDMA over Converged Ethernet),在vSphere 6.5版本中即已提供。

在維運K8s時,如果遇到實體資源不足須再增添Worker節點,實體機的作法就只能再架設一台,即使是採用Ansible等自動化部署工具,皆需要一段安裝建置時間。相較之下,「PKS則是透過Resize叢集指令即可立即擴充,大約兩分鐘安裝完成Kubo並加入K8s,就可以產生一個Worker節點。」

PKS定位並非僅提供K8s叢集,而是打造完整的架構,可運行多個K8s,而且藉由自行修復能力讓IT人員毋須介入維運。若資源不足時,輸入指令集即可彈性擴充,IT人員只要專注於維運已相當熟悉的vSphere即可提供開發者所需的容器環境。


追蹤我們Featrue us

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

我知道了!