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

市場上具備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串接整合。如此應用場景，若以混合雲架構，影像傳送到公有雲端平台執行辨識，才得以省去高額頻寬費用開支。