**來源|**[**阿里巴巴雲原生公眾號**](https://mp.weixin.qq.com/s/P9OYU6S_DfA9XH2Xg_JXkw)

近日，GitHub 上的 Go 語言趨勢榜出現了一個新的專案 —— KubeVela。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/56caf25b64604df098f0697da45432b8.png)

據專案官方文件，KubeVela 是“一個簡單易用且高度可擴充套件的應用管理平臺與核心引擎，KubeVela 是基於 Kubernetes（K8s）與 Open Application Model（OAM）技術構建的”。

在雲原生浪潮席捲全球的今天，相信大家對 K8s 肯定不會陌生，那麼 KubeVela 和 OAM 又是什麼技術呢？事實上，K8s 的大名雖然已經路人皆知，但在很多社群網友的反饋中，我們似乎看到圍繞 K8s 的雲原生生態目前只是幾家頭部大廠的專屬。很多一線業務同學都反饋 K8s 太複雜了，太難學了，如果沒有大廠的投入和技術儲備來基於 K8s 構建出場景化的上層平臺出來，要落地雲原生技術，感覺根本搞不定。

而去年十月，阿里雲與微軟合作共同開源了 [OAM 專案](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247487043&idx=1&sn=088457a1dccd6578290c9291a968bf16&chksm=fae5058ccd928c9a618c2763c8dcf74348e2198ba532a1095f0d9292da44f8d1b2a9f8cf4342&scene=21#wechat_redirect)，旨在為雲原生生態提供一個**以應用為中心**的、統一的上層抽象技術，從而大大降低業務研發同學上手雲原生技術的門檻，真正享受到雲原生帶來的極致敏捷與研發效能提升。而剛剛釋出的 KubeVela 專案，正是 OAM 模型在 Kubernetes 上的完整實現。

如今距離 OAM 專案開源正好過去一年， 那麼 OAM 專案如今有何進展？本次釋出的 [KubeVela 專案](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247496420&idx=1&sn=3c7f079c40fde0ea915c3960b8939062&chksm=fae6f92bcd91703d8cc7f8584a050efd6cfe9c62d5801d89ce7799bcc595dadf54b7ad2544ea&scene=21#wechat_redirect)又將為國內的 K8s 生態帶來哪些影響？帶著這些問題，我們與 KubeVela 專案背後的設計者之一、CNCF 應用交付領域小組 co-chair、官方大使，來自阿里雲的工程師張磊，詳細的聊了聊。

### 採訪嘉賓介紹

![2.jpg](https://ucc.alicdn.com/pic/developer-ecology/e72f2fac13ef45b68087d7933b3a275c.jpg)

以下為採訪原文：

## 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 自己的應用。這些方法，都是達成“簡單易用、又高度可擴充套件”這兩個目標的重要技術手段。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/7296bccac5f34e4fbd3b210634d6b1e3.png)

## 4. 具體到某一位使用者要使用 KubeVela 平臺，比如我是一個商城業務開發者，我如何在實際生產過程中部署和使用 KubeVela? 作為一個平臺工程師，我又如何使用 KubeVela 呢？

****：KubeVela 只有一個二進位制檔案，所以它的部署非常簡單。在任何一個 Kubernetes 叢集已經就緒的情況下，下載這個二進位制檔案後執行 vela install 命令即可。

而使用 KubeVela 就更加簡單了。比如我們們商城業務開發，他從始至終都不需要關心 KubeVela 和 Kubernetes 的存在，只需要在程式碼庫中完成開發和本地測試，然後加上一個如下所示的 Appfile 放在程式碼庫中即可。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/3a45bc7130654d6fa915a669cfb1f424.png)

這個 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：

![5.png](https://ucc.alicdn.com/pic/developer-ecology/1f5257f5ac774c5f9ca39f666f62c345.png)

上述 Appfile 的最後一部分，就是我們們新增的 metrics 能力。怎麼樣，非常簡單吧？大家可能會好奇，那麼這樣一個能力的“描述檔案“，裡面的內容到底長什麼樣子呢？

別急，KubeVela 的官方文件裡提供了詳細的例子和指南：[https://kubevela.io/#/en/platform-engineers/trait](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 （即：外掛能力管理命令）的[使用文件](https://kubevela.io/#/en/developers/cap-center)。

## 6. 能否就雲原生相關生態在國內的發展趨勢發表一些您的觀點和看法？

****：正如前面講到的，不止國內，其實整個雲原生生態在接下來的發展方向，可以說是“迴歸初心”。

雲原生技術與理念發展至今，在基礎設施抽象層已經取得了空前的成就。當然，這裡的所有一切都是圍繞著 Kubernetes 專案來進行的。但我們們也提到，光有基礎設施抽象是遠遠不夠的。我們們雲原生的最終目標是給業務使用者帶來價值，用雲原生與生俱來的彈性和敏捷，幫助業務使用者更快、更好、更有信心的去開發與交付應用。而至於 Kubernetes 也好，容器也罷，都是實現這個目標的手段而不是目的。所以，雲原生髮展的方向一定會繼續朝這個目標前進，比如為了進一步解決業務使用者以語言無關的方式對流量與服務進行治理的訴求，就出現了 Service Mesh。而今天 OAM 與 KubeVela 專案的出現，則是在所有這些能力之上，回答“最後一公里”的問題：我們如何把這些能力高效、敏捷、透過”以應用為中心“的方式交付給業務使用者？讓他們真的能夠像使用 Heroku 那樣使用 Kubernetes 和 Istio？

這種“讓業務研發專注於寫程式碼”體驗，說起來簡單，宣傳起來也很贊，但從雲原生技術誕生到現在，在整個雲原生生態的持續努力下，這件事情依然只解決了一小部分。而如今，KubeVela 專案的提出與釋出，正是雲原生生態繼續推動這件事情向終態前進的一個縮影。希望 KubeVela 這樣的專案，能夠讓構建簡單易用又高可擴充套件的雲原生應用平臺從大廠專屬的“陽春白雪”，變成“小菜一碟”，讓越來越多的團隊能夠快速、高效、高質量的基於 Kubernetes 生態能力池構建出符合自己訴求的、各種各樣的上層平臺，讓雲原生技術能夠真正落地到各行各業中開花結果。

專訪 CNCF 大使張磊：讓雲原生不再是大廠專屬

相關文章