混合雲平台全面容器化 K8S一統應用架構江山

近兩年開源技術堆疊正逐步推動IT應用框架的變革,從Hypervisor虛擬化系統,演進到容器(Container)技術,基於Docker實作搭配Kubernetes(簡稱K8S)調度(Orchestration)管理叢集,以秒級的速度自動擴充,確保應用服務不中斷,幾乎已成為數位化IT發展的戰略目標。

市場上具備PaaS技術的供應商,不論是以公有雲或私有雲模式提供,皆已陸續跟進支援K8S引擎服務,亦稱之為CaaS(Container as a Service)或KaaS(Kubernetes as a Service)型態,例如微軟日前發布正式版的Azure Kubernetes Service(AKS)與VMware PKS(Pivotal Container Service)。

調度工具降低維運容器架構門檻

微軟合作夥伴暨商務事業群技術架構顧問蔡宗佑觀察,容器化應用初期是來自於開發團隊所驅動,有助於加速驗證程式運行效能與功能項目,只是多年來僅停留在開發環境,主因正是欠缺完整的叢集維運機制。

「過去多年來探討由開發者與維運者共同合作的DevOps工作模式,我認為這兩個角色如今應顛倒成OpsDev。」蔡宗佑說。之所以有如此觀點,主要是因為從App開發完成到實際上線服務,期間過於冗長,必須得縮短週期加快上線速度,問題是開發者通常認為只須確認功能項目、程式碼正常運行即可,並不關心網路層的配置,那理應交由維運團隊負責。

但實際上卻發現,維運團隊本身需要具備最基本的開發能力,才有辦法與開發團隊進行對談。同時要具備架構能力,懂得如何建立流程自動化,讓開發過程更為順暢。難度之高,使得容器化在早期驗證過程中僅只適合開發團隊「自用」,當維運管理、監控機制,甚至網路功能逐步開始補齊之後,容器化應用才足以邁向企業市場。日前發布正式版的AKS,正是著眼於此。

如今的微軟Azure雲端平台已開始提供容器家族服務,包含的Azure Container Instance(ACI)容器執行個體、Azure Container Registry(ACR)儲存映像檔,以及AKS與Azure Container Service(ACS)叢集管理服務。

蔡宗佑不諱言,微軟相當清楚以往開放社群的成見,常有人不看好微軟發展開源的策略,直到原本任職於Google的K8S共同創辦人之一Brendan Burns於2016年加入,並帶領Azure開發團隊研發容器服務等專案,並且持續地在GitHub社群貢獻程式碼,才逐漸證明微軟走向開源陣營的決心。 微軟的發展策略較具獨特之處,蔡宗佑指出,首先是K8S開源社群仍舊持續不斷地在更新版本,一旦釋出,AKS產品研發團隊承諾會在一週內納入支援,由用戶自行決定是否升級;其次是微軟擁有龐大企業客戶,以及累積幾十年的領域知識,具有足夠資源協助建構新興應用架構。畢竟現階段放眼台灣,除了新創以及在社群較為活躍的公司以外,大部分企業對於DevOps角色定位的資源相當匱乏,勢必得由研發工程師,或者是維運人員,身兼多職來發展新應用架構,這也是企業評估AKS的主因。

虛擬層與原生容器環境並存

▲微軟合作夥伴暨商務事業群技術架構顧問蔡宗佑指出,微軟Azure公有雲服務的發展,主要是為協助中大型企業應用需求設計,較其他以新創公司為主要客群的設計思維不同,更有足夠領域知識協助企業建置穩定運行的整體架構。
儘管Docker搭配K8S為目前最火紅的組合,被多數企業寄予厚望,但蔡宗佑強調,並非所有應用場景皆適用。「以往測試Docker時,大多是啟用虛擬主機,安裝Linux作業系統與Docker引擎,之後創建Dockerfile,Docker Compose則可Build映像檔,接著把映像檔推送存放到Docker Hub,一連串的動作都是自行逐步完成。ACI容器執行個體服務則可省略這些步驟,只要一行指令即可啟動,透過Token機制驗證從ACR儲存區拉回映像檔。」

對於社群或新創公司而言,本就具備從頭開始自建以彈性地配置環境的控管能力;但是對於企業應用環境來說,更在意的是穩定運行架構,在服務上線服務之前勢必得經過不斷地測試驗證可行性。ACI容器執行個體本身已完成環境配置,讓用戶只須專注建置自己的映像檔,畢竟虛擬化與容器化為完全不同的技術,先基於ACI熟悉操作指令與邏輯,可降低維運人員進入門檻,經過嘗試錯誤的學習過程,逐漸累積操控能力,同時也驗證與測試系統建立於容器環境的可行性。

此外,Docker叢集結構管理工具並非只有K8S,早期建置者可能已採用DC/OS(資料中心/作業系統)、Docker Swarm等叢集管理工具,雖然在K8S統一Docker世界後已逐漸式微,若既有運行的環境要進行變更,勢必得經歷一段痛苦的異動過程,因此企業若選擇持續沿用,則可透過ACS叢集管理服務搭配更具彈性的開源專案ACS引擎(ACS-E)來協助。

他進一步說明,早期只有ACS時,客戶想要採用K8S,但AKS又尚在預覽版本,在缺乏管理節點機制之下,通常會有兩個選擇,一是完全依照地端建置方式,底層透過虛擬主機來運行;另一個方式是運用ACS-E提供樣本檔案來協助撰寫配置方法,就如同Dockerfile檔案的邏輯,即可自動啟用虛擬主機所需的元件。「ACS-E服務已有許多企業採用,甚至有應用在區塊鏈環境,底層採用ACS-E,搭配K8S執行維運,看重的即是ACS-E彈性能力。」

雖然當前眾所注目的服務項目為AKS,但是微軟並未打算用以取代其他容器家族服務。「不論是GKE(Google Container Engine)、Amazon EKS、AKS,皆是管理部分的叢集,就雲端平台的角度來看,屬於PaaS的K8S服務項目,運行環境中勢必會有許多環節用戶無法觸碰,例如底層實體資源,這是必然的現象。但為了堅持符合開源社群原生的精神,我們仍舊會持續發展ACS-E,讓用戶得以選擇適用的服務,亦可依照自己的方式建立Dockerfile。」 其實在K8S基礎之下,公有雲服務供應商發展的技術邏輯差異不大,以維運監控機制來看,Amazon提供Cloud Watch,Google稱為Stackdriver,Azure則為OMS(Operations Management Suite),包含較多組合元件。以前監控範疇主要是針對實體主機與虛擬主機,不外乎查看網路流量、硬碟I/O、CPU等狀態,以免發生服務中斷。演進到容器環境時,OMS服務則可支援Application Insight,針對Pod所包含的應用程式,實作應用程式生命週期管理(ALM)監控。

Hatchway開源專案自動掛載抽象磁區

▲VMware資深技術顧問何宗憲觀察,公有雲服務業者目前的客群主要是新創、中小企業等IT人員配置不多的公司,但未來若欲持續提升營收,勢必須鎖定較不熟悉的中大型規模企業,發展整合地端建構混合、多雲應用模式。
在容器環境架構中,一旦監控時發現故障,只要映像檔、部署程式碼、運行所需的資料皆備齊,重新建置新容器可能較問題排除速度更快。VMware資深技術顧問何宗憲以IT領域廣為流傳的「寵物與牲畜」形容,虛擬主機即如同寵物,必須有人細心照顧;牲畜則是容器,隨時可進行宰殺。只是當用戶正在輸入資料時,假設運行資料庫的容器突然關機,雖不至於影響整體服務,卻可能造成當下輸入的資料未能來得及寫入而遺失。

「前述的狀況為全狀態(Stateful)特性,暫存檔存放在容器環境,實際上,容器環境的更適合無狀態(Stateless),不配置任何記憶功能。至於暫存檔,則可於外部建立Etcd存放鍵值(Key-value),另一種方式是存放在硬碟,只是必須手動掛載,稱為Persistent Volume。」何宗憲說。

在Kubernetes 1.8版本之後,開始增添PVC(Persistent Volume Claim)與Storage Class定義資源方法,對此VMware PKS基於vSphere撰寫驅動程式釋出的Hatchway開源專案已可整合,只要是VMware支援的資料儲存模式,不論是外部的iSCSI、NFS,或是VMware vSAN,可直接在YAML描述檔案中包含PVC,不用再如同以往手動操作把虛擬主機上的Volume掛載到容器,只要載入PVC檔案即可自動地在資料儲存區域新增並掛載VMDK。

「K8S為了符合開發者需要快速產生新環境需求,底層的IT基礎架構可藉由預先配置自動化掛載,開發者只要在容器環境中納入PVC到Metadata,就會自動在Datastore中新增VMDK,立即可用。」何宗憲說。以GCP為例,搜尋K8S叢集環境中的服務,通常只會看到Kube-Proxy,若整合Open Service Broker API,在GCP環境中可透過指令,運用Google BigQuery、Cloud SQL等服務,可直接在GCP平台上增添PKS的容器啟用發布。

至於叢集環境的監看與維運,VMware提供vRops輔助,讓維運者可透過拓樸圖呈現方式查看,可深入到各個叢集中的Pod運行狀態,例如處理器、記憶體等用量資訊。同時,去年VMware經由收購取得Wavefront亦加入支援,只要把Wavefront Proxy建置在K8S叢集環境,資料會被遞送到公有雲的SaaS,維運者可基於K8S階層架構查看運行資訊。

地端彈性調度公有雲資源以降低開支

雲端原生應用程式固然是當前最受關注的議題,企業期能藉此發展新型態的營運模式,但是並非全數採用公有雲服務,更多傾向於建立混合型架構來提供服務。何宗憲進一步說明,以使用者實際存取應用服務的行為來看,企業架構模式通常是把連線入口建置在自家內部,部分的Workload遷移到公有雲,例如台灣已有銀行開始採用雲端空間存放經過加密保護的檔案,以降低龐大資料量耗用的儲存開支,但存取入口的Workload仍舊保留在地端。

「使用者連線入口為外部雲端平台,才屬於公有雲服務,前述的例子則只是私有雲的延伸,VMware Cloud on AWS發展策略即是著眼於此,連線並非直接從AWS進入;同樣的,VMware、Pivotal、Google整合而成的PKS也是。PKS架構在GCP之上,可直接調用BigQuery等服務,但是屬於私有雲延伸到GCP,執行資料處理時,會被視為Google資料中心內部傳遞,毋須支付頻寬費用。在資料經過分析後產出的商業智慧報表,拋送回到企業才需要收取網路費用,因此得以節省相當多的頻寬費用。」

畢竟一旦開始採用公有雲平台上的服務,隨即會被綁定,K8S調度工具採用YAML檔案為標準格式,可運行在多平台環境,正是特別受到企業青睞的主因。然而,若採用API服務,屬於各家雲端平台供應商的獨特技術,則難以彈性遷移。最顯著的例子即為人工智慧應用,雲端服務供應商提供的影像與語音辨識技術,多數企業無自主研發能量,只能透過API串接整合。如此應用場景,若以混合雲架構,影像傳送到公有雲端平台執行辨識,才得以省去高額頻寬費用開支。


追蹤我們Featrue us

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

我知道了!