簡介： 如今距離 OAM 項目開源正好過去一年， 那麼 OAM 項目如今有何進展？本次釋出的 KubeVela 項目又将為國内的 K8s 生态帶來哪些影響？帶着這些問題，我們與 KubeVela 項目背後的設計者之一、CNCF 應用傳遞領域小組 co-chair、官方大使，來自阿裡雲的工程師張磊，詳細的聊了聊。
來源|阿裡巴巴雲原生公衆号
近日，GitHub 上的 Go 語言趨勢榜出現了一個新的項目 —— KubeVela。
據項目官方文檔，KubeVela 是“一個簡單易用且高度可擴充的應用管理平台與核心引擎，KubeVela 是基于 Kubernetes（K8s）與 Open Application Model（OAM）技術建構的”。
在雲原生浪潮席卷全球的今天，相信大家對 K8s 肯定不會陌生，那麼 KubeVela 和 OAM 又是什麼技術呢？事實上，K8s 的大名雖然已經路人皆知，但在很多社群網友的回報中，我們似乎看到圍繞 K8s 的雲原生生态目前隻是幾家頭部大廠的專屬。很多一線業務同學都回報 K8s 太複雜了，太難學了，如果沒有大廠的投入和技術儲備來基于 K8s 建構出場景化的上層平台出來，要落地雲原生技術，感覺根本搞不定。
而去年十月，阿裡雲與微軟合作共同開源了 OAM 項目，旨在為雲原生生态提供一個以應用為中心的、統一的上層抽象技術，進而大大降低業務研發同學上手雲原生技術的門檻，真正享受到雲原生帶來的極緻靈活與研發效能提升。而剛剛釋出的 KubeVela 項目，正是 OAM 模型在 Kubernetes 上的完整實作。
如今距離 OAM 項目開源正好過去一年， 那麼 OAM 項目如今有何進展？本次釋出的 KubeVela 項目又将為國内的 K8s 生态帶來哪些影響？帶着這些問題，我們與 KubeVela 項目背後的設計者之一、CNCF 應用傳遞領域小組 co-chair、官方大使，來自阿裡雲的工程師張磊，詳細的聊了聊。
采訪嘉賓介紹
以下為采訪原文：
1. 請給還不了解 OAM 的朋友介紹一下 OAM 和 KubeVela 項目吧。
<張磊>：Kubernetes 和雲原生技術的各種核心概念，距離咱們業務使用者其實是很遙遠的。實際的落地過程也告訴我們，僅僅有基礎設施層抽象，離雲原生“絲般順滑”的雲端應用管理與傳遞體驗，還是存在着巨大的鴻溝。在 Kubernetes 與使用者之間，還存在着一層名叫“應用層”抽象亟待填補。是以，很多業務使用者對“雲原生”、Kubernetes 的價值其實普遍缺乏體感，這個情況不僅在阿裡裡面存在，在整個社群裡也是個讓人頭疼的問題。隻有咱們的業務研發接觸到的是“代碼”、“應用”而不是“Pod”、“StatefulSet”，那麼“讓研發專注于寫代碼”這個美好、樸素的雲原生願望，才能夠真正實作。
而 Open Application Model（OAM）開放應用模型，以及它的 Kubernetes 實作 KubeVela 項目，正是阿裡雲聯合微軟等雲原生社群中堅力量，共同推出的“以解決使用者側訴求”為核心的雲原生應用層項目。其中，OAM 的設計思想是為包括 Kubernetes 在内的任何雲端基礎設施提供一個統一、面向最終使用者的應用定義模型；而 KubeVela，則是這個統一模型在 Kubernetes 上的完整實作。對于業務研發人員來講，KubeVela 可以被認為是雲原生社群的 Heroku。而對于平台團隊來講，KubeVela 由于具備極高的可擴充性，則可以被認為是一個“以應用為中心”的、高度可擴充的 Kubernetes 發行版。而 OAM 項目，這是 KubeVela 背後的核心 API 範式和插件化能力管理模型。
2. 距離 OAM 釋出整整一年，有哪些新增玩家參與了項目的建設工作，送出了哪些貢獻？是否已經生産可用，或者還存在哪些需要完善的地方？
<張磊>：在現今的 OAM 社群中，有大量的貢獻來自 Oracle、MasterCard、Upbound.io、騰訊、位元組跳動、第四範式、和滿幫集團等十餘家技術公司與團隊，他們不僅是 OAM 社群重要的技術力量，很多還是 KubeVela 項目的早期發起者。事實上，現在的 OAM 模型和它的 Kubernetes 實作 KubeVela 項目，本身就是阿裡雲原生應用基礎設施的核心元件，支撐着包括阿裡雲 EDAS 服務、阿裡集團核心 PaaS、阿裡雲邊緣計算平台、達摩院 AI PaaS 在内的多個網際網路級平台的核心的運作與擴充。而在接下來的設計中，OAM 社群會以 KubeVela 為核心，在已經生産可用的平台層模型的基礎上，繼續建設面向開發者的使用者側模型，并且以此為基礎通過 Dapr sidecar 和 Istio 來完善應用層中間件與流量治理能力，實作“讓雲原生應用傳遞輕松愉悅（Make shipping applications more enjoyable）”的目标。
3. KubeVela 定義為“簡單易用又高度可擴充應用管理平台”，該項目背後的思考是什麼？其“簡單易用又高度可擴充”這兩大特性又是如何實作的？
<張磊>：今天，Kubernetes 為我們建構出了一個統一的基礎設施抽象層，為平台團隊屏蔽掉了“計算”、“網絡”、“存儲”等過去我們不得不關注的基礎設施概念。但當我們把視角從平台團隊提升到垂直業務系統的最終使用者（如：應用開發人員）的時候，我們會發現 Kubernetes 這樣的定位也為應用開發者們帶來了挑戰和困擾。比如，太多的使用者都在抱怨 Kubernetes “太複雜了”。究其原因，其實在于 Kubernetes 中的核心概念與體系，主要是面向平台團隊而非最終使用者設計的。缺乏面向使用者的設計不僅帶來了陡峭的學習曲線，影響了使用者的使用體驗，拖慢了研發效能，甚至在很多情況下還會引發錯誤操作乃至生産故障（畢竟不可能每個業務開發人員都是 Kubernetes 專家）。
這也是為什麼在雲原生生态中，幾乎每一個平台團隊都會基于 Kubernetes 建構一個上層平台給使用者使用。最簡單的也會給 Kubernetes 做一個圖形界面，稍微正式一些的則往往會基于 Kubernetes 開發一個類 PaaS 平台來滿足自己的需求。理論上講，在 Kubernetes 生态中各種能力已經非常豐富的今天，開發一個類 PaaS 平台應該是比較容易的。
然而現實卻往往不盡如人意。在大量的社群訪談當中，我們發現在雲原生技術極大普及的今天，基于 Kubernetes 建構一個功能完善、使用者友好的上層應用平台，依然是中大型公司們的“專利”。這裡的原因在于：Kubernetes 生态本身的能力池固然豐富，但是社群裡卻并沒有一個可擴充的、友善快捷的方式，能夠幫助平台團隊把這些能力快速“組裝”成面向最終使用者的功能（Feature）。
這種困境帶來的結果，就是盡管大家今天都在基于 Kubernetes 建構上層應用平台，但這些平台本質上卻并不能夠與 Kubernetes 生态完全打通，而都變成一個又一個的垂直“煙囪”。這些平台都無一例外的引入了自己的專屬上層抽象、使用者界面和插件機制。這裡最典型的例子包括經典 PaaS 項目比如 Cloud Foundry，也包括各種 Serverless 平台。是以，作為一個公司的平台團隊，我們實際上隻有兩個選擇：要麼把自己局限在某種垂直的場景中來适配和采納某個開源上層平台項目；要麼就隻能自研一個符合自己訴求的上層平台并且造無數個社群中已經存在的“輪子”。
那麼，有沒有”第三種選擇”能夠讓平台團隊在不造輪子、完全打通 Kubernetes 生态的前提下，輕松的建構面向使用者的上層平台呢？
KubeVela 就是這樣一個面向使用者的上層平台項目。對于業務開發者來說，KubeVela 簡單、易用，它可以讓開發者以極低的心智負擔和上手成本在 Kubernetes 上定義與部署應用。而關開發者隻需要編寫一個 docker-compose 風格應用描述檔案 Appfile 即可，不需要接觸和學習任何 Kubernetes 層的相關細節。但更重要的是，對于平台團隊來說，KubeVela 可不是一個簡單的 PaaS 或者 Serverless，它是一個能夠以 Kubernetes 原生的方式進行任意擴充的 PaaS 核心，平台工程師可以基于它建構出任意的垂直業務系統。
在具體實作上，KubeVela 通過 OAM 模型，對雲原生生态中的能力進行了面向使用者側的抽象，同時也做到了 KubeVela 中的任何一個功能都是插件。基于這種設計，KubeVela 以可插拔式的方式内置了 Flagger，KEDA 等社群先進的釋出、擴容技術作為預設能力，又以 Kubernetes 原生的方式提供了可以一鍵接入任何生态能力的高可擴充性。同時，對使用者提供了一個 docker-compose 風格的 Appfile 來讓使用者以極簡的方式描述如何 build，deploy 和 release 自己的應用。這些方法，都是達成“簡單易用、又高度可擴充”這兩個目标的重要技術手段。
4. 具體到某一位使用者要使用 KubeVela 平台，比如我是一個商城業務開發者，我如何在實際生産過程中部署和使用 KubeVela? 作為一個平台工程師，我又如何使用 KubeVela 呢？
<張磊>：KubeVela 隻有一個二進制檔案，是以它的部署非常簡單。在任何一個 Kubernetes 叢集已經就緒的情況下，下載下傳這個二進制檔案後執行 vela install 指令即可。
而使用 KubeVela 就更加簡單了。比如咱們商城業務開發，他從始至終都不需要關心 KubeVela 和 Kubernetes 的存在，隻需要在代碼庫中完成開發和本地測試，然後加上一個如下所示的 Appfile 放在代碼庫中即可。
這個 20 來行的配置檔案，指定了咱們這個商城應用的鏡像打封包件（Dockerfile），運作類型（type），啟動指令（cmd），通路所需的路由和域名（route），以及水準擴容的政策（autoscale）。所有這些配置項，全部都是 KubeVela 提供的面向使用者的上層抽象，不需要了解底層 Kubernetes 的任何細節和執行機制。而作為使用者，隻需要執行一句：vela up，一個完整的、可以立即域名通路、會自動擴容的應用就會被釋出到 Kubernetes 上運作起來。這個 vela up 操作，也可以接入到 CI/CD 流水線當中，讓 Git 去觸發。
值得一提的是，上面所有的這些配置項具體有哪些、每個項有哪些字段可以讓使用者填？這些都是平台管理者可以随時配置、調節、并且修改立即生效的。這種平台層高度靈活和快速響應的靈活性，是網際網路時代軟體開發與疊代的重要保證。
而對于平台開發者來說，他使用 KubeVela 的主要方式，就是通過 Kubernetes 來管理這些抽象和能力。他可以随時往 KubeVela 裡安裝新的能力。這些能力可以是 Kubernetes 社群裡已有的插件，也可以是平台團隊自己開發的 CRD controller。而所有這些操作隻需要一行指令：kubectl apply -f trait.yaml。
這個 trait.yaml 實際上就是一個“能力”的描述檔案，它的内容是對該能力應的 CRD 的引用和使用者模闆。比如，我們可以把 Kubernetes 社群的監控 CRD 作為一個應用監控能力（起名叫做 metrics）安裝到 KubeVela 中，那麼效果就是，平台的使用者立刻就能夠在 Appfile 裡新定義一個配置項，叫做 metrics：
上述 Appfile 的最後一部分，就是咱們新增的 metrics 能力。怎麼樣，非常簡單吧？大家可能會好奇，那麼這樣一個能力的“描述檔案“，裡面的内容到底長什麼樣子呢？
别急，KubeVela 的官方文檔裡提供了詳細的例子和指南：https://kubevela.io/#/en/platform-engineers/trait
5. 那麼 KubeVela 項目是一個 PaaS 嗎？
<張磊>：大多數經典 PaaS 都能提供完整的應用生命周期管理功能，同時也非常關注提供簡單友好的使用者體驗，提升研發效能。在這些點上，KubeVela 跟經典 PaaS 的目标，是非常一緻的。
但另一方面，經典 PaaS 往往是不可擴充的（比如 Rancher 的 Rio 項目），或者會引入屬于自己的插件生态（哪怕這個 PaaS 是完全基于 Kubernetes 建構的），以此來確定平台本身的使用者體驗和能力的可控制性（比如 Cloud Foundry 或者 Heroku 的插件中心）。
相比之下，KubeVela 的設計是完全不同的。KubeVela 的目标，從一開始就是利用整個 Kubernetes 社群作為自己的“插件中心”，并且“故意”把它的每一個内置能力都設計成是獨立的、可插拔的插件。這種高度可擴充的模型，背後其實有着精密的設計與實作。比如，KubeVela 如何確定某個完全獨立的 Trait 一定能夠綁定于某種 Workload Type？如何檢查這些互相獨立的 Trait 是否沖突？這些挑戰，正是 Open Application Model（OAM）作為 KubeVela 模型層的起到的關鍵作用，一言以蔽之：OAM 是一個高度可擴充的應用定義與能力管理模型。
KubeVela 和 OAM 社群歡迎大家設計和制作任何 Workload Type 和 Trait 的定義檔案。隻要把它們存放在 GitHub 上，全世界任何一個 KubeVela 使用者就都可以在自己的 Appfile 裡使用你所設計的能力。具體的方式，請參考 vela cap （即：插件能力管理指令）的使用文檔。
6. 能否就雲原生相關生态在國内的發展趨勢發表一些您的觀點和看法？
<張磊>：正如前面講到的，不止國内，其實整個雲原生生态在接下來的發展方向，可以說是“回歸初心”。
雲原生技術與理念發展至今，在基礎設施抽象層已經取得了空前的成就。當然，這裡的所有一切都是圍繞着 Kubernetes 項目來進行的。但咱們也提到，光有基礎設施抽象是遠遠不夠的。咱們雲原生的最終目标是給業務使用者帶來價值，用雲原生與生俱來的彈性和靈活，幫助業務使用者更快、更好、更有信心的去開發與傳遞應用。而至于 Kubernetes 也好，容器也罷，都是實作這個目标的手段而不是目的。是以，雲原生發展的方向一定會繼續朝這個目标前進，比如為了進一步解決業務使用者以語言無關的方式對流量與服務進行治理的訴求，就出現了 Service Mesh。而今天 OAM 與 KubeVela 項目的出現，則是在所有這些能力之上，回答“最後一公裡”的問題：我們如何把這些能力高效、靈活、通過”以應用為中心“的方式傳遞給業務使用者？讓他們真的能夠像使用 Heroku 那樣使用 Kubernetes 和 Istio？
這種“讓業務研發專注于寫代碼”體驗，說起來簡單，宣傳起來也很贊，但從雲原生技術誕生到現在，在整個雲原生生态的持續努力下，這件事情依然隻解決了一小部分。而如今，KubeVela 項目的提出與釋出，正是雲原生生态繼續推動這件事情向終态前進的一個縮影。希望 KubeVela 這樣的項目，能夠讓建構簡單易用又高可擴充的雲原生應用平台從大廠專屬的“陽春白雪”，變成“小菜一碟”，讓越來越多的團隊能夠快速、高效、高品質的基于 Kubernetes 生态能力池建構出符合自己訴求的、各種各樣的上層平台，讓雲原生技術能夠真正落地到各行各業中開花結果。
原文連結：https://developer.aliyun.com/article/779819?
版權聲明： 本文内容由阿裡雲實名注冊使用者自發貢獻，版權歸原作者所有，阿裡雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿裡雲開發者社群使用者服務協定》和《阿裡雲開發者社群知識産權保護指引》。如果您發現本社群中有涉嫌抄襲的内容，填寫侵權投訴表單進行舉報，一經查實，本社群将立刻删除涉嫌侵權内容。