近日，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 生態能力池構建出符合自己訴求的、各種各樣的上層平臺，讓雲原生技術能夠真正落地到各行各業中開花結果。
本文為阿里雲原創內容，未經允許不得轉載。