在 KubeVela 項目發佈之後，不少國內外的社區同窗們都會問到一個相似的問題：KubeVela 的體驗真的很是棒，能夠說是 Kubernetes 上的 Heroku 了。這麼看來， KubeVela 跟 Heroku 這樣的 PaaS 產品究竟是不是一類項目呢？數據庫
今天，咱們就專門來聊一個這個話題：KubeVela 與 PaaS 有何不一樣？後端
備註：本文所提到的 PaaS，既包括 Heroku 這樣的經典 PaaS 產品，也包括各類各樣的基於 Kubernetes 的「雲原生」 PaaS。它們雖然底層實現不一樣，可是對用戶提供的使用接口和體驗是類似的。但 OpenShift 是一個例外，做爲一個比 Kubernetes 自己還複雜的項目，OpenShift 不屬於本文所討論的簡單易用、面向用戶的 PaaS 之列，而是一個地道的 Kubernetes 發行版。
首先，咱們先說結論：KubeVela 可以爲用戶帶來很是接近 PaaS 的體驗，但 KubeVela 並非 PaaS。服務器
爲何說 KubeVela 不是 PaaS？
大多數 PaaS 都能提供完整的應用生命週期管理功能，同時也很是關注提供簡單友好的用戶體驗，以及對研發效能的提高。在這些點上，KubeVela 跟 PaaS 的目標和提供的用戶體驗，是高度一致的。但若是你去研究 KubeVela 的實現細節，就不難發現 KubeVela 的總體設計與實現其實與各種 PaaS 項目的差異是很是大的。若是從用戶視角來看，這些區別則會直接反應在整個項目的「可擴展性」上。架構
進一步來講，PaaS 的用戶體驗雖好，但卻每每是不可擴展的。咱們能夠直接拿比較新的 Kubernetes PaaS，好比 Rancher Rio 項目來看。這個項目提供了很好的應用部署體驗，好比 Rio run 來讓你快速部署一個容器化應用、自動分配域名和訪問規則等等。可是，若是咱們想讓 Rio 支持更多的能力以知足不一樣的用戶訴求呢？app
好比：框架
- 可否幫助我運行一個 定時任務？
- 能不能幫我運行一個 OpenKruise 的 CloneSet 工做負載？
- 能不能幫我運行一個 MySQL Operator？
- 能不能根據個人自定義 metrics 來作水平擴容？
- 能不能基於 Flagger 和 Istio來幫我作漸進式灰度發佈？
- 能不能 ……
而這裏的關鍵點在於，上述這些能力在 Kubernetes 生態中都是很是常見的的能力，有的甚至是 Kubernetes 內置就能夠支持。但是到了 PaaS 這裏，要支持上述任何一個能力，都必須對 PaaS 進行一輪開發，並且因爲先前的一些假設和設計，甚至極可能須要大規模的重構。運維
舉個例子，我有一個 PaaS 系統，它全部的應用都是經過 Deployment 來執行的，那麼這個 PaaS 的發佈、擴容等功能，也都會直接按照 Deployment 來進行實現。而如今，用戶提出了原地升級的訴求，須要讓這個 PaaS 再支持 CloneSet，那整套系統極可能就得掀翻重來。再到運維能力這一側，這個問題會更加嚴重，好比如今這個 PaaS 支持的是藍綠髮布策略，那麼它跟流量管理、監控系統等依賴之間，都是須要大量交互和集成的。而如今咱們要讓 PaaS 支持一個新的策略叫作「金絲雀」發佈，那麼全部的這些交互和執行邏輯基本全得重重構一遍，工做量是巨大的。模塊化
固然，並非全部的 PaaS 都徹底沒有可擴展性。工程能力比較強的 PaaS，好比 Cloud Foundry 和 Heroku，它們都提供了本身的插件能力和插件中心，在確保平臺自己的用戶體驗和能力的可控制性的前提下開放必定的插件能力，好比容許用戶接入本身的數據庫，或者開發一些簡單的 Feature 進去。但這種插件機制不管怎麼作，說白了只能是這個 PaaS 專屬的封閉小生態能力。而在雲原生時代，咱們開源社區已經有了 Kubernetes 生態這樣一個近乎「無限」的能力池，在這個能力池面前，任何 PaaS 專屬的小生態都顯得太蒼白無力了。學習
上述問題，咱們能夠統稱爲 PaaS 的「能力困境」。ui
相比之下，KubeVela 的目標從一開始就是利用整個 Kubernetes 生態做爲本身的「插件中心」，而且「有意」把它的每個內置能力都設計成獨立的、可插拔的插件。這種高度可擴展的模型，背後其實有着精密的設計與實現。好比，KubeVela 如何確保某個徹底獨立的 Trait 必定可以綁定於某種 Workload Type？如何檢查這些相互獨立的 Trait 間是否存在衝突？這些挑戰正是 Open Application Model（OAM）做爲 KubeVela 模型層的起到的關鍵做用，一言以蔽之：OAM 是一個高度可擴展的應用定義與能力裝配模型。
並且，你們設計和製做任何 Workload Type 和 Trait 的定義文件，只要存放在 GitHub 上，全世界任何一個 KubeVela 用戶就均可以在本身的 Appfile 裏使用這些能力。具體的方式，請參考 $ vela cap （即：插件能力管理命令）的使用文檔。
因此說，KubeVela 提倡的是一種面向將來的雲原平生臺架構，這種架構認爲：
- 應用平臺自己架構完全模塊化，其全部的能力都是可插拔的，而平臺核心框架經過模型層提供標準化的能力封裝與裝配流程。
- 該流程可以無縫接入雲原生生態中的任何應用管理能力，使得平臺工程師徹底專一於能力自己的研發和基於該模型的能力封裝過程，使平臺團隊在爲用戶帶來簡單易用的平臺層抽象的同時，快速、敏捷地響應用戶變幻無窮的應用管理訴求。
KubeVela 總體架構與能力可插拔機制
KubeVela 總體架構以下圖所示：
在架構上，KubeVela 只有一個 controller 而且以插件的方式運行在 Kubernetes 之上，爲 Kubernetes 帶來了面向應用層的抽象，以及以此爲基礎的面向用戶的使用界面，即Appfile。Appfile 乃至 KubeVela 運行機制背後的核心，則是其能力管理模型 Open Application Model (OAM) 。基於這個模型，KubeVela 爲系統管理員提供了一套基於註冊與自發現的能力裝配流程，來接入 Kubernetes 生態中的任意能力到 KubeVela 中，從而以「一套核心框架搭配不一樣能力」的方式，適配各類使用場景（好比 AI PaaS，數據庫 PaaS 等等）。
具體操做上，做爲系統管理員或者平臺開發者，上述能力裝配流程容許他們把任意的 Kubernetes API 資源（含 CRD）以及對應的 Controller 做爲「能力」一鍵註冊到 KubeVela 中，而後經過 CUE 模板語言將這些能力封裝成用戶可用的抽象（即成爲 Appfile 中的一部分）。
接下來，咱們就來 Demo 一下如何將 kubewatch 這個社區中的告警機制直接插入到 KubeVela 中做爲一個告警 Trait 來使用：
Step 1：將平臺能力註冊爲 OAM 對象
首先，你須要肯定 CRD 所表示的能力是對應一個 Workload Type 仍是 Trait？這裏的區別在於 Workload Type 指的是如何運行你的代碼。而 Trait 指的是如何運維、管理或者操做已經運行起來的代碼實例。
而 KubeWatch 做爲一種告警機制，天然做爲 Trait 來使用的。這時候，咱們就能夠經過寫一個 TraitDefinition yaml 來將它註冊：
KubeVela 內置的服務器端 Runtime 會識別監聽的 TraitDefinition 註冊事件，而後將該能力歸入平臺管理中。
這一步完成，KubeVela 就已經註冊完畢在 KubeVela 平臺中可用了。但接下來咱們還須要將它暴露給用戶使用，因此須要定義這個能力對外的使用接口。
Step 2：編寫 CUE template 來封裝對外暴露接口
實際上，大多數社區能力雖然很強大，但對於最終用戶來都比較複雜，學習和上手很是困難。因此在 KubeVela 中，它容許平臺管理員對能力作進一步封裝以便對用戶暴露簡單易用的使用接口，在絕大多數場景下，這些使用接口每每只有幾個參數就足夠了。在能力封裝這一步，KubeVela 選擇了 CUE 模板語言，來鏈接用戶界面和後端能力對象，而且自然就支持徹底動態的模板綁定（即變動模板不須要重啓或者從新部署系統）。下面就是 KubeWatch Trait 的模板例子：
將這個模板放到 Definition 文件中並 $ kubectl apply -f 到 Kubernetes 中，KubeVela 就會自動識別和處理相關輸入。這時候，用戶就能夠直接在 Appfile 中聲明使用剛加進來的能力了，好比發送告警信息到指定的 Slack channel：
能夠看到，這個 kubewatch 的配置是咱們經過三方擴展進來的一個新的能力，經過 KubeVela 平臺管理 Kubernetes 擴展能力就是這麼簡單快速。有了 KubeVela，平臺開發人員就能夠簡單快速地在 Kubernetes 上搭建起一個 PaaS，且可以將任何一個 Kubernetes 能力快速封裝成面向最終用戶的上層抽象。
以上示例，僅僅是 KubeVela 可擴展性的「冰山一角」。在後續的文章中，咱們會繼續詳細介紹 KubeVela 能力裝配流程中更多的細節問題，好比：
- 如何定義能力之間的衝突關係與協做關係？
- 如何快速的定義 CUE 模板文件？
- 如何基於 CUE 語言定義出功能強大的「能力模塊」，而後把這些模塊安裝到 KubeVela 中？
- 等等 ……
總結
原生的可擴展性與能力裝配機制，是 KubeVela 與大多數 PaaS 項目的根本性不一樣，這也致使 KubeVela 背後的實現和模型跟它們相比也有着本質性的差別。因此說，KubeVela 的核心目標，乃是在爲用戶帶來簡單易用的應用管理體驗的同時，爲平臺管理員提供徹底 Kubernetes 原生的可擴展性與靈活度。
做者：鄧洪超 阿里雲高級技術專家， 人稱 「Kubernetes Operator 第二人」，OAM 與 KubeVela 項目核心維護者。
本文爲阿里雲原創內容，未經容許不得轉載。