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

來源|阿里巴巴雲原生公衆號

近日，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 項目背後的設計者之1、CNCF 應用交付領域小組 co-chair、官方大使，來自阿里雲的工程師張磊，詳細的聊了聊。

採訪嘉賓介紹

如下爲採訪原文：

1. 請給還不瞭解 OAM 的朋友介紹一下 OAM 和 KubeVela 項目吧。

<張磊>：Kubernetes 和雲原生技術的各類核心概念，距離我們業務用戶實際上是很遙遠的。實際的落地過程也告訴咱們，僅僅有基礎設施層抽象，離雲原生「絲般順滑」的雲端應用管理與交付體驗，仍是存在着巨大的鴻溝。在 Kubernetes 與用戶之間，還存在着一層名叫「應用層」抽象亟待填補。因此，不少業務用戶對「雲原生」、Kubernetes 的價值其實廣泛缺少體感，這個狀況不只在阿里裏面存在，在整個社區裏也是個讓人頭疼的問題。只有我們的業務研發接觸到的是「代碼」、「應用」而不是「Pod」、「StatefulSet」，那麼「讓研發專一於寫代碼」這個美好、樸素的雲原生願望，纔可以真正實現。

而 Open Application Model（OAM）開放應用模型，以及它的 Kubernetes 實現 KubeVela 項目，正是阿里雲聯合微軟等雲原生社區中堅力量，共同推出的「以解決用戶側訴求」爲核心的雲原生應用層項目。其中，OAM 的設計思想是爲包括 Kubernetes 在內的任何雲端基礎設施提供一個統1、面向最終用戶的應用定義模型；而 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 生態能力池構建出符合本身訴求的、各類各樣的上層平臺，讓雲原生技術可以真正落地到各行各業中開花結果。