如何理解容器技術平臺的不同姿態

本文講的是如何理解容器技術平臺的不同姿態【編者的話】最近，在微軟加入CNCF基金會僅一個月之後， 亞馬遜也宣佈加入成為白金會員，至此，全球主要公有云服務商都加入了CNCF。可以說這是以Kubernetes為代表的容器技術平臺的全面勝利。Kubernetes火爆之初，有人擔心它會衝擊Cloud Foundary為代表的PaaS平臺。 事實上，作為PaaS一哥，Cloud Foundary依舊有著穩定的生態和忠實的使用者。而有意思的是，一度如日中天的IaaS平臺卻意外受傷。同時，在AWS Lamda釋出後，Serverless熱度暴增，各大雲平臺紛紛推出Serverless服務。

【3 天燒腦式基於Docker的CI/CD實戰訓練營 | 北京站】本次培訓圍繞基於Docker的CI/CD實戰展開，具體內容包括：持續整合與持續交付（CI/CD）概覽；持續整合系統介紹；客戶端與服務端的 CI/CD 實踐；開發流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及實踐經驗分享等。

無論Kubernetes、Cloud Foundary還是Serverless，其背後驅動都是容器技術，但技術熱點快速輪動，常常也給開發者／使用者帶來困擾，究竟什麼時候該用什麼平臺／技術？是否契合所面臨的問題？本文希望圍繞Kubernetes、Cloud Foundary和Serverless做一些粗淺分析，嘗試提供一個理解不同容器化技術／平臺的視角。

圖 1 2014年7月至今，Kubernetes（藍線）和Cloud Foundary（紅線）的搜尋趨勢變化

圖 2 2015年7月至今，Kubernetes（藍線），Cloud Foundary（紅線）和Serverless（黃線）的搜尋趨勢變化

開發執行一個應用，在Kubernetes、Cloud Foundary和Serverless平臺上各需做哪些事情

假如一個工程師要分別在Kubernetes、Cloud Foundary和Serverless（例如，OpenWhisk）上開發／執行同一個應用，例如實現一個排序應用， 我們分析一下，大概各自要做哪些事情。

在Kubernetes上，開發人員一般需做以下幾步：

1. 編寫應用程式碼；
2. 構建應用容器映象，並上傳到相應的容器映象中心；
3. 建立一個Kubernetes叢集；
4. 把相應的容器部署到剛建立的Kubernetes叢集中；
5. 測試並確認應用成功上線。

而在Cloud Foundary或Serverless 上，所需工作可簡化為三步：

1. 編寫應用程式碼；
2. 更新配置檔案並把應用釋出到雲上；
3. 測試並確認應用成功上線

應用上線之後，考慮到應用彈性和業務可靠性，Kubernetes和Cloud Foundary應用還需再做一步，即擴充套件出多個例項，而Serverless則什麼也不用做。

上述步驟總結如表1：

表 1 Kubernetes、Cloud Foundary和Serverless部署執行應用步驟

從這個簡化的例子看，假如用Serverless實現，使用者要做的最少，只需提供編寫除錯好的程式碼就可以了；使用Cloud Foundary，使用者要關注的稍微多一點，如執行時設定彈性擴張；而用Kubernetes的話，使用者要做的就相對複雜些，不僅要提供應用所依賴的runtime環境，而且還要自己製作容器映象，併發布到相應的registry，同時還要考慮構建整個部署環境的Kubernetes叢集等等。

圖 3 各*aaS中使用者管理和平臺功能的劃分

結合IaaS和SaaS，圖3把三種基於容器的計算模式，從使用者和平臺兩個角度作一個更為通用的描述。可以看到，從IaaS，CaaS（Kubernetes），PaaS（Cloud Foundary），FaaS（Serverless），最後到SaaS，平臺提供的越來越多，使用者要做的越來越少。下面通過理解Kubernetes，Cloud Foundary和Serverless的主要定位，再做進一步分析。

Kubernetes、Cloud Foundary和Serverless期望解決的問題

容器很重要的特點之一是快速構建一個跨平臺執行的應用及所依賴的環境。無論Serverless、Cloud Foundary還是Kubernetes，都以其作為技術平臺基礎，但由於想解決問題不同，所以各自側重也不同。

Kubernetes社群發展很快，也孵化了很多新專案，而所有這些都圍繞其基本定位，即容器編排，或者說scheduling，即決定什麼東西（pod）跑在哪兒（node），以達到相應的可用性（serviceability）。Kubernetes極大簡化了使用者對容器（應用載體）的管理，大大提升了應用維護的靈活性和可控性。此外，它對底層基礎架構抽象相對較少，使得使用者依然可對資源有較全面的管理；

Cloud Foundary作為PaaS，希望能為使用者解決除了應用開發之外的所有事情。 它提供了幾乎所有語言的buildpack，也提供了service broker的機制，方便應用整合外部服務，同時還自帶容器管理元件，解決應用部署問題。對於開發者來說，開發應用之後，幾乎只需執行Cloud Foundary push一條命令，其餘的事情都可交由平臺處理完成。這使使用者更加專注應用本身，並從應用管理，中介軟體管理和部署環境等大量而繁瑣的工作中解放出來。但由於平臺對整個流程／Stack的完整封裝，使用者在享受巨大便利的同時，一定程度上也被限制了對底層資源的靈活排程，進而影響應用的可能形態。

Serverless按照Martin Fowler的定義，可以分為兩類，一是極大依賴於第三方服務的應用（通常稱作BaaS “Backend as a Service”）， 二是依賴於跑在非持久容器上特定程式碼的應用（通常稱作FaaS “Function as a Service”） 。我們通常討論的Serverless，如AWS Lambda，Apache OpenWhisk屬於後者。FaaS型別Serverless的典型場景是觸發-響應，即根據定義的事件執行相應的功能（一段程式碼）。使用者只需關心事件定義和響應動作，所有其他事情交由平臺處理，包括根據請求進行自動迅速地彈性擴張，響應結果儲存所需的儲存等。就像Serverless的名字一樣，使用者不需要關心任何伺服器，無論是物理伺服器，中介軟體伺服器，還是資料伺服器，就像它們不存在一樣，甚至都不用關心應用，使用者只需做好事件觸發後的響應功能。 

對於Kubernetes和Cloud Foundary，Ubuntun的 CEO Mark Shuttleworth曾說過，“對於我們而言，Kubernetes是引擎，是渦輪機，是PaaS平臺的核心，而Cloud Foundary則是個完整的PaaS”（圖4），而關於PaaS和Serverless，現在是AWS雲端計算戰略副總的Adrian Cockcroft也曾有個同樣形象的評論，“如果一個PaaS，為一個只需執行半秒的任務，可以在20毫秒之內啟動許多例項，那就可稱為Serverless”（圖5）。

圖 4 Mark Shuttleworth關於Kubernetes和Cloud Foundary的評論

圖 5 Adrian Cockcroft關於PaaS和Serverless的評論

這兩段評論可以幫助我們對Kubernetes、Cloud Foundary和Serverless之間的定位有更清晰的理解。Kubernetes只是對容器進行管理的一種技術，而非平臺，Cloud Foundary則是完整PaaS平臺，容器管理（Diego）是其重要元件，是平臺整個技術stack裡的一環，而Serverless則是某類特殊PaaS，它充分利用了容器瞬間啟動和能快速彈性擴充套件的特性。

Mark的類比非常形象，我們不妨順著他的思路聯想一下。假如Kubernetes是個引擎，這意味著它是動力，可以構建拖拉機，也可以構建汽車，或者變成輪船的驅動；那麼Cloud Foundary就是整車了，使用者只能根據使用者手冊在適合的道路條件下使用它，換個胎是可以的，但想隨時改底盤懸掛，換髮動機是困難的。那Serverless呢？也許可以看作是固定線路班次的公共交通，比如飛機，高鐵，按時間觸發，從某地到另一地，如遇突發流量，管理部門就會增加班次或加掛車廂。

靈活度vs易用性——一切為了創新

既然三者之間有如此清晰的定位， 為什麼貌似Kubernetes一枝獨秀？為什麼Cloud Foundary過時了或Serverless只能用於簡單功能之類的聲音會不時響起呢？ 根據上面討論，可以看到，從Kubernetes，到Cloud Foundary，再到Serverless，其實是對底層stack不同程度的抽象，隨著抽象程度提高，降低了對實現棧的控制，其目的就是把關注更集中於業務邏輯的實現。

抽象，用另一詞來替代，就是封裝。封裝一般都會簡化底層邏輯，遮蔽相應細節，限制對底層某些功能的訪問，所以使用者在獲得便利性和易用性的同時，必然以失去一部分靈活性為代價，同時也影響了應用的適用範圍，例如Cloud Foundry對IaaS資源的需求，由BOSH通過一個叫CPI（Cloud Platform Interface）的介面實現，這個介面把對計算，儲存和網路的操作簡化成十幾種，一般情況下夠用了，但操作粒度和靈活度的確值得商榷。

圖 6 各*aaS上開發應用靈活度 vs 易用性的對比

我們在圖3上加些標註，改成如圖6所示。從IaaS，CaaS（Kubernetes），PaaS（Cloud Foundary），FaaS（Serverless）到SaaS，隨著抽象程度提高，使用者關注度越來越集中於業務邏輯本身，而代價就是對技術實現棧的控制越來越小，對應用調整的靈活度也越來愈弱。魚和熊掌不可兼得，如何在靈活度和易用性之間進行折中，往往需要基於實際業務場景考量。

假如我們希望構建一個能服務於不同規模，不同型別的雲端計算服務平臺， 把Kubernetes作為核心引擎顯然是一個非常有吸引力的想法。通過把核心引擎的能力暴露出來，並圍繞核心引擎，豐富完善基礎服務，以微服務鬆耦合的方式組合，就能適應各種業務場景，構建複雜應用。

對於一個企業，如果其專注點不是提供雲服務，而是迅速構建創新業務應用，那一個Cloud Foundary的PaaS平臺能幫到很多。企業開發人員根據業務需求，利用Cloud Foundary平臺開發應用，繫結所需服務，並通過整合的CI/CD流程，讓應用從開發，測試，staging到生產，一氣呵成，業務迅速釋出。在一個業務需求變化迅速，應用生命週期越來越短的時代，把程式設計師從與業務實現不相關的工作中解脫出來意義巨大。

Serverless則完全從業務場景出發。設想一個大型企業集團的財務人員，每個月末或季末都要統計大量的財務資料，一般情況下，可以用財務軟體，但當財務指標，報表格式發生變化，計算公式發生調整時，提交軟體變更可能是個複雜的過程，這時採用公有的Serverless服務無疑是高效的做法。另外，Serverless以功能為物件，可以在某種程度上降低對程式碼能力的要求，業務人員也有可能直接參與功能實現，讓功能不僅as a service，而且還是自助服務。相信這也是Serverless演進目標，即無程式碼功能實現，變成App-less。關於這點，我們似乎可從微信小程式看到些什麼。

演進，容器技術平臺還會發生什麼？

以上分析討論是基於Kubernetes、Cloud Foundary和Serverless的現狀，如從演進角度看，它們之間的關係和定位也許很快會改變。

回想容器興起之初，很多人覺得它的能力和效能還不足與虛機相比，但隨著容器技術的迅速發展，尤其是容積編排技術的巨大威力，懷疑的聲音已經很少了，甚至有硬體提供商宣稱，今後出貨的伺服器不再預裝虛擬化層，而改裝容器管理平臺。從這個意義上講，CaaS/ Kubernetes更像是IaaS的升級，這也是為什麼Kubernetes火了以後，IaaS受到一定衝擊的原因。

同樣，由於歷史原因，Cloud Foundary雖也有優美的容器管理元件Diego，但它的能力卻不能為應用開發人員充分利用。假如Cloud Foundary能開放Diego，或者能對其他容器管理技術開放，那Cloud Foundary push顯然能做更多事情，服務於更復雜的應用場景，這無疑對技術人員和企業都是福音。

現在，技術越來越開源化、社群化，Kubernetes、Cloud Foundary和OpenWhisk都有各自非常活躍的社群。社群最大的優勢是利於技術的迅速傳播，而我們在各個社群裡也看到很多相互借鑑或融合專案，無疑，這是推進技術快速演進的方法。

後記

這篇讀書體會是一年多前寫的《彎道超車：容器技術究竟為雲端計算帶來了什麼？》的下篇， 也是最近讀了相關資料（連結如下）後的一點感想。出發點是試圖理清一個困惑，即，如何能在迅速理解技術熱點的同時，也能瞭解其相互關係和演進的內在邏輯。我想，這也是文中大牛，如Adrian Cockcroft、Mark Shuttleworth和Martin Fowler為什麼總能有一言蔽之的金句的原因 。

參考

1. Container vs Serverless — https://www.slideshare.net/Dan … tions
2. Serverless Architecture: A Gentle Overview — https://www.slideshare.net/Cod … rview
3. Mark Shuttleworth訪談1 — http://www.datamation.com/open … .html
4. Mark Shuttleworth訪談2 — http://www.datamation.com/clou … .html

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
作者介紹

鄢達來，IBM雲端計算方案開發經理。

原文釋出時間為：2017-08-21

本文作者：鄢達來

本文來自雲棲社群合作伙伴Dockerone.io，瞭解相關資訊可以關注Dockerone.io。

原文標題：如何理解容器技術平臺的不同姿態