開源項目的演進會遇到哪些“坑”？KubeVela 從發起到晉級 CNCF 孵化的全程回顧

作者：孫健波、曾慶國

2023 年 2 月，**KubeVela [ 1] ** 經過全體 ToC 投票成功進入 CNCF Incubation，是雲原生領域首個晉級孵化的面向應用的交付和管理平臺。KubeVela 背後的核心理念是 2019 年阿里雲和微軟聯合發佈的開放應用模型（OAM），演變至今，KubeVela 通過其可編程可擴展的架構、良好的用戶體驗，以及大量的生態核心能力，幫助了釘釘、招商銀行、理想汽車、移動雲、百度等數百家企業構建其雲原生應用平臺，大大降低了雲原生技術的使用門檻。

KubeVela 本身也有別於“大廠開源”的慣性模式，它從第一天起就遵循“社區發起、開放治理、國際化運作”的原則，核心理念之一就是“始終以業界的最廣泛和最真實場景作爲項目演進的指南針”，所以發展路徑中一直在傾聽社區的聲音，以最普遍、最共性的需求爲最高優先級。因此，我們也有幸經歷了一個項目從社區發起到用戶羣體壯大的全過程。從技術迭代、完善功能，到社區運營、開源治理，再到打磨產品、建立生態，我們克服了諸多困難，這或許是開源項目都會遇到的挑戰。

今天，我們將做一個完整的回顧，梳理項目演進過程中的那些“坑”，希望對整個開源生態的發展有所幫助。

項目發起：明確目標和定位

一個開源項目的發起，其最核心的是明確項目的目標和定位。 OAM/KubeVela 誕生之初的 2018-2019 年，當時我們判斷：隨着雲原生技術逐漸統一基礎設施和工作負載層面的抽象，如何進一步簡化和標準化應用交付與管理層面的操作和功能，會成爲接下來一個非常自然的演化方向，也會成爲市場的下一個焦點。這裏面我們主要考慮了四個方面：

• 受衆

大多數開發者，也就是最終業務應用的開發者，他們日常關心的是應用開發和部署，而不是計算存儲網絡，這意味着應用層的大幅簡化和標準化一定會成爲強需求。

• 定位和空間

Kubernetes 非常明確的要把它的抽象層次停留在基礎設施層，這爲應用層的進一步創新和工作提供了足夠的空間和支撐。

• 行業格局

在 Kubernetes 逐漸成爲事實標準的背景下，大多數技術（比如 OpenShift）依然在做侷限的封裝，而原生的工具（如 helm、kustomize）又過於簡單。這樣既不滿足雲上用戶碎片化、多樣化的使用訴求，也無法打造用戶友好的使用體驗。

• 技術儲備

CRD Operator， Terraform 等 IaC 技術的逐步普及提供了一個快速交付可編程、模塊化的應用管理抽象，而基於 Kubernetes，一個獨立的應用管理和交付系統可以非常專注於該層本身，而無需關注基礎設施層的問題。

基於以上趨勢的判斷，阿里開始在 2019 年逐步佈局應用交付與管理領域，提出了一系列先導性探索和實踐，包括 Helm/Kustomzie 應用管理、多集羣應用交付 [ 2] 等。最終確定將“讓軟件交付在當今流行的混合、多雲環境中變得更加簡單、高效、可靠”作爲我們的核心目標和願景，將“一個與基礎設施無關的、用戶友好但又靈活可擴展的應用交付抽象”作爲我們的核心交付物，這個應用交付抽象就是今天的 OAM spec，而隨後出現的 KubeVela 則是這一層抽象的具體實現。

圖 1：KubeVela 是什麼？

明確的目標和定位不僅支撐了 KubeVela 開源團隊以及大量社區貢獻者可以在相對鬆散的模式下長期協作，還幫助團隊從大量雜亂的需求中解放出來，專注在最核心的問題域中。 比如 KubeVela 不會觸及工作負載本身，用戶可以選擇集成 Kubernetes 原生的 Deployment，或者自己擴展 CRD Operator，又或者選擇 OpenKruise 這樣的工作負載管理工具。同時團隊專注於項目的集成能力和擴展性，比如我們投入了足夠的精力去做 Kubernetes API 的編排，任意的 Kubernetes 資源都可以在 KubeVela 體系中組合、拆分、查看狀態、傳遞參數，這一特性使得 KubeVela 早期快速的打出了自己的市場定位，並且獲得了像第四範式這樣的早期用戶。

早期演進：明確要堅守的核心技術原則

開源項目的早期通常是沿着最初設定的目標去補齊核心功能，在此之前我們可能需要回答一個問題：“爲了讓我們的開源項目與衆不同，我們該遵循怎樣的設計原則？ ”

KubeVela 項目的第一個年頭是核心技術功能初步形成的階段，設計之初我們給項目定下的關鍵原則是：

• Kubernetes 原生

OAM 應用模型不侷限於 Kubernetes 生態，但是我們選擇將 KubeVela 控制平面通過 Kubernetes 的插件（CRD）模式實現。一方面它充分利用了 Kubernetes 聲明式 API 面向終態的設計理念，爲用戶帶去易用性和確定性，方便用戶安裝和使用。 另一方面它也幫助我們利用 Kubernetes 的 API 生態，快速實現了諸如 Helm 交付、彈性擴縮容、服務網關、灰度發佈等應用所需的核心能力，而 KubeVela 團隊隨後發佈的 **Terraform Controller 項目 [ 3] **也證明了基於 Kubernetes 控制平面銜接雲能力的可行性。

• 可擴展

KubeVela 基於 OAM 模型提供用戶友好的上層抽象，但這些抽象可以隨時擴展以滿足用戶的各種需求。這給技術實現帶來了很大的挑戰，但這也是一個非常重要的創新，它避免了 KubeVela 項目成爲一個只能解決“最小公分母”問題的“雞肋”項目。

• 可編程

在衆多的可擴展性設計中，KubeVela 最終選擇了 Infra as Code(IaC) 的可編程擴展方式。因爲這種擴展方式不僅簡單易用，還可以方便的模塊化和插件化。這個選擇不僅提供了擴展 KubeVela 的最佳方案，還爲後來的插件市場等生態能力打下了基礎。

圍繞着這些原則，項目選擇基於 **CUE 配置語言 [ 4] **來作爲動態編程能力的基石，KubeVela 1.0 及早期版本給出了一個非常靈活的 OAM 實現。但項目的演進也使得 KubeVela 及 OAM 模型與早期發佈的版本形成了較爲明顯的差異，這裏形成了一個不小的挑戰，即“開源項目的兼容性如何保證”。

圖 2：KubeVela 可編程可擴展的模塊化設計？

持續迭代：保持開源項目的兼容性

KubeVela 基本上就是在 OAM 社區的衆多用戶呼聲下誕生的，那些早期參與貢獻的工程師們，他們其實也同時是公司裏面積極推進 OAM 落地的平臺構建者，他們不僅提供了大量的建議和代碼貢獻，還通過自身的實際場景幫助社區做驗證。我們知道一個新技術的推廣，很重要的一點是在解決原有問題的同時，儘可能降低採納的成本，也就是不引入新的問題。 所以當 KubeVela 發佈的第一個版本的時候，我們的早期採納者他們更多的是在做一個自身 OAM 實踐的升級，而不是使用一個全新的系統。同樣地，在後續的項目迭代過程中，對兼容性的考量一直都放在首要的位置。當 KubeVela 項目的第一階段功能實現完成，並被開源社區逐步採用的過程中。根據大量的用戶反饋和調研，我們發現，除了基礎的工作負載和運維需求之外，用戶還會有諸如多集羣高可用、資源共享、資源回收等應用管理策略的需求，而看似非常碎片化和複雜的各類應用交付場景，其背後確實存在一個非常本質的模型，那就是“工作流”。我們很快就開始同時演進 OAM 模型本身，並且在 KubeVela 實現了一個非常輕量級的工作流引擎。而“工作流”這個特性本身就又與 Kubernetes 和 GitOps 生態天然互補，KubeVela 的工作流步驟可以任意擴展，而聲明式 API 面向終態的語義也可以很好的描述工作流的狀態機，這使得 KubeVela 的工作流幾乎可以滿足任何交付場景的需要，所以這個創新後來也成爲了 KubeVela 被大量採用的“殺手鐗”。

圖 3：KubeVela 1.0 發佈後始終保持功能以及模型層面的兼容性

當然這也會爲技術方案的長期演進帶來很多包袱和困難，所以我們在隨後也加入了項目功能的廢棄機制，僅對少量不合理、且幾乎沒有用戶的功能做廢棄，並且在正式廢棄前提前兩個版本做通知。核心能力形成的過程中，我們觀察到用戶增長並不滿足預期。通過運營分析，我們發現無論是 Github 還是官網，初次訪問流量是比較大的，但實際轉化數據不太理想。此時我們意識到項目的使用體驗可能不盡如人意，而社區用戶的使用和反饋是驅動我們項目持續增長的重要輸入。

用戶轉化：注重易用性和首次體驗

KubeVela 的理念是業界領先的，所以我們一直在做大量佈道，許多用戶被我們吸引過來。然而許多用戶反饋說，看了 KubeVela 項目官網，看不懂這個項目是做什麼的。此時我們意識到，項目的易用性出了問題。我們把自己從項目維護者的身份中走出來，開始作爲用戶審視這個項目，對於首次接觸項目的新用戶，我們問自己三個問題：

• 第一個問題：我能一下子看明白項目解決的是什麼問題嗎？

KubeVela 項目本身是有一定的理解門檻的，它建立在 OAM 應用模型之上，OAM 模型關注點分離的核心思路又把平臺的用戶分成了平臺的構建者和最終用戶，這給直接接觸 KubeVela 的用戶帶來了不小的認知成本。在 1.0 到 1.5 這接近一年的時間中，我們每次發版都會根據用戶的反饋持續重構我們官網的文檔，以廣大用戶最能產生共鳴的關鍵詞、場景進行類比，同時也一直在做減法，將項目的高級功能藏到相對較深的位置。

另一方面，我們在產品實現上也持續明確目標用戶羣體，將 KubeVela 控制器核心定位給平臺工程師，而開發的 VelaUX 子項目初始定位是業務開發者開箱即用，同時也爲平臺工程師構造企業平臺提供參考和基礎框架。通過明確定位的產品培養用戶心智，進而將越來越多關鍵信息傳播給社區用戶，再通過用戶社羣持續影響更廣泛的生態。

• 第二個問題：我能一下子聯想到我的場景是否能夠用它嗎，或者它能滿足我的需求嗎？

用戶的注意力是有限的，通過對官網的用戶訪問數據進行分析，我們發現新用戶在網站的平均駐留時間不超過 3 分鐘，如何在有限的時間裏迅速抓住目標用戶的興趣，文檔結構的設計非常重要。通過對社區用戶的大量訪談，我們意識到大多數用戶會帶着需求關鍵詞來尋覓項目，所以們不斷調整官網側邊欄目錄，把項目能夠實現的核心功能以用戶熟悉的關鍵詞體現到導航目錄中方便用戶快速匹配。

除了項目文檔，另一個關鍵點是提煉用戶案例，行業頭部用戶案例具備很強的帶動作用。有一段時間理想汽車率先採納了 KubeVela，沒多久就看到了小鵬汽車的採納，甚至在不久前，自動駕駛領域的巨頭 Aurora 也在 Slack 上聯繫我們，計劃全公司採納 KubeVela，而招商銀行的案例也帶動了一大批金融行業的用戶採納 KubeVela。當然這些案例的積累是一個小火慢燉的過程，很難一蹴而就。 這不僅需要項目的維護者對於社區用戶有足夠的耐心，也需要站在開源項目背後支撐項目發展的公司有足夠的遠見， 我們非常感謝阿里雲、招商銀行、Napptive等公司的維護者們持續而堅定的投入。

• 第三個問題：我想試一下項目的實際運行效果，我能在幾分鐘只能快速體驗完整的 Demo 嗎？

這個問題其實涉及到了開源項目的一個關鍵特點，那就是開源項目必須能夠用戶自助，即用戶要有能力自發的安裝、使用、運維，以及在社羣進行傳播。如果一個開源項目是大多數用戶自己玩不起來的，那註定難以成功。所以我們在每次發版時都會檢查以下兩項：

1. 大多數用戶能否順暢進行安裝？對於國際化運作的 KubeVela 項目來說，我們需要幫助用戶客服網絡障礙，不管是訪問文檔還是下載安裝都需要在國內外流暢進行；爲了降低安裝複雜度，我們甚至專門發起了一個叫 **VelaD [ 5] **的項目，幫助用戶從單機一鍵離線拉起包括 Kubernetes 在內的完整體驗環境，大大降低了用戶的上手門檻。除此之外，還有包括 ARM 架構鏡像支持、版本升級一鍵完成等體驗優化。

2. 第一個用例是否足夠簡單又充分說明項目特性？KubeVela 早期的第一個用例要麼過於簡單看不出功能特點，要麼過於複雜沒有多個集羣都跑不起來。經過持續打磨，現在的第一個用例圍繞着核心概念，體現了工作負載抽象、交付策略、多集羣、工作流等核心能力，但對用戶環境又無額外要求。

圖 4：VelaD 全離線一鍵安裝包括 Kubernetes 集羣在內的完整環境

逐步成熟：產品化運作和社區用戶

隨着項目的逐步成熟，社區會迎來一批又一批的用戶，而開源項目成功的核心就是大量的用戶採納。KubeVela 很幸運，一直有阿里巴巴內部大量的場景可以幫助打磨孵化，而我們也非常注重社區用戶的需求。除了每週定期舉辦國內外社區會議，還會組織跟不同企業的點對點交流會，甚至幫助他們制定完整的平臺架構。而這個過程的積累也是相互的，KubeVela 維護團隊從各行各業的頭部企業中瞭解了行業的現狀和差異化痛點，得以從更廣闊的視野做功能的設計。

在社區用戶的過程中，我們也總結了一些關鍵經驗：

1. 如何給到開源用戶安全感？ 對於基礎設施類的開源項目，一旦採納就會成爲企業內部核心架構的一部分，相比於企業內部自建，採納開源往往會缺乏一些安全感，開源項目本身如何給到企業安全感至關重要。首先是項目維護團隊的多樣化、長期穩定性以及高活躍，KubeVela 是 CNCF 託管的孵化項目，背後有阿里雲、招商銀行、Napptive 等多個公司在持續維護。同時要持續對代碼質量保持較高的要求、注重安全問題和穩定性，KubeVela 有 40 多項持續集成測試條目，總體測試覆蓋率超過 60%，核心場景的覆蓋率在 90% 以上，基本上每個合併的代碼都能保證兼容性，同時對代碼貢獻者本身的能力也有較高的要求。而團隊對安全問題的上報和穩定性問題也始終保持高度敏感，一旦發現會第一時間發佈修復版本。最後是提供確定性，有明確的里程碑、發版計劃 ，並且堅定的執行。 KubeVela 發佈至今每隔 2-3 個月發佈一次大版本，每隔 1-2 周發佈一個小版本，社區一直保持極高的活躍度，至今已經發布了超過 150 個版本，每個版本都有清晰的變更文檔。

2. 如何平衡社區用戶的小衆需求？ 社區用戶在落地過程中由於場景的差異，必然會產生相對小衆的需求。對於這一點，我們的策略是 Blocker Issue 優先，即如果由於一些功能設定和實現直接阻礙了場景落地，那麼這類問題要第一時間解決。對於功能新增類的需求，則交由社區一同評估等待更多的反饋，確認是一個相對普遍的需求再加入到版本計劃中。例如 KubeVela 早期有一些用戶希望對接他們企業內部的統一認證平臺，這可能並不是標準的協議模式，通過社區 Issue 的來會討論，有貢獻者指出採用了 Dex 作爲企業單點登錄的統一方式，不同企業自行對接 Dex 即可。這使得項目能夠羣策羣力，着眼於長遠發展。

3. 如何獲得海外用戶？ 基礎設施領域的開源項目，要想獲得真正意義上的成功，如何打開國際化市場是一個繞不開的話題。一方面，項目本身要始終着眼於領域的最前沿，保持技術的先進性，聆聽國外用戶的使用場景和習慣，對技術發展趨勢做出敏銳的判斷。另一方面，KubeVela 的核心團隊均在國內，也克服了包括時差、語言、文化在內的諸多客觀困難，一直堅持在北美相對合適的時間召開社區會議，持續在 KubeCon 等各類海外大會佈道，文檔、文章始終用中英文雙語發佈，同時積極活躍在 Slack、Issue 中答疑，滿足國外用戶希望點對點溝通交流的訴求。這不僅需要項目維護者有較強的綜合實力，也需要對項目真正的熱愛。 團隊也在積極培養海外貢獻者，隨着 KubeVela 生態的不斷繁榮，Napptive、Guidewire 等企業合作伙伴也在陸續加入社區，共同承擔項目維護的職責。

圖 5：OAM/KubeVela 風雨無阻的國外社區會議

生態建設與社區運營

最後我們要談一談社區生態，因爲做好一個開源項目絕不僅僅是做一項前沿的技術，它更像是在目標領域打造一款好的產品。除了打磨產品功能，我們還需要通過對項目持續運營、對社區治理，得到更多開發者的認可，讓他們參與進來貢獻。要實現這樣的目標，就需要讓開發者對 KubeVela 形成共識、主動加入並參與協作。

KubeVela 誕生於 OAM 社區，也是第一個將“以應用爲中心”的設計理念落地的項目。因此早期，我們首先要讓大家理解 OAM 模型的思想，大家纔會有意願開始瞭解 KubeVela 是什麼。我們做了大量的佈道，並聯合 CNCF 發佈業界首個“雲原生技術公開課”，介紹 OAM“以應用爲中心”的理念如何解決雲原生時代應用開發問題，得到了越來越多開發者的共鳴。發展到 2021 年 5 月，阿里雲聯合信通院發佈業內首個以 OAM 爲核心的“雲計算開放架構”標準，將 OAM “模型”化虛爲實，也對 KubeVela 發展起到關鍵作用。

爲使社區保持持續的生命力，2021 年 7 月，KubeVela 正式加入 CNCF ，項目受衆也擴大至全球。我們投入了很多精力做海外運營，比如聯動 CNCF TAG App Delivery，以及 Argo、FluxCD、Prometheus、K3s 等生態夥伴舉辦社區會議、在主流的海外開發者社區建立團隊賬號，漸漸將影響力滲透到北美、日本、西班牙、英國等多個國家。爲了讓周邊生態繁榮起來，以便能夠讓項目在更大的領域得到廣泛的傳播，爲此我們專門建立了一個插件（Addon）體系，方便社區裏的開發者可以將生態項目的集成，方便地製作成一個具備版本、統一倉庫、可發現、可分發、一鍵安裝的插件包。

圖 6：KubeVela 的插件生態

KubeVela 的技術很先進，社區的貢獻者衆多，但水平也有差異，爲了保證項目的質量，又不打擊貢獻者的積極性。對於每一個代碼提交，我們都會及時響應、充分交流，給予貢獻者足夠的尊重和耐心。同時我們會積極的補充開發者文檔，將開發者遇到的常見問題體系化整理。另一方面，我們也建立了完善的開發者晉級機制，從組織的 member，到 reviewer、approver 最後到 maintainer，都有明確的達成條件，讓開發者像打怪升級一樣有成就感。

如今 KubeVela 貢獻者已經遍佈全球，所在的企業和組織超過 70個。我們倡導的理念是，開源貢獻的形式不只是代碼，一次分享、一次解答，都是對項目的貢獻。我們也在建立並逐步完善社區晉升模型和協作機制，讓大家更規範、高效地參與社區。KubeVela 社區依然非常年輕，還有很多事情在逐步完善，很開心有這麼多朋友同行，讓這個隊伍越來越壯大。也期待更多朋友來到 KubeVela 社區感受開源的魅力。

您可以通過如下材料瞭解更多關於 KubeVela 以及 OAM 項目的細節：

• 項目代碼庫：
  github.com/oam-dev/kubevela
  歡迎 Star/Watch/Fork！
• 項目官方主頁與文檔：kubevela.io
  從 1.1 版本開始，已提供中文、英文文檔，更多語言文檔歡迎開發者進行翻譯。
• 項目釘釘羣：23310022；Slack：CNCF #kubevela Channel
• 加入微信羣：請先添加以下 maintainer 微信號，表明進入KubeVela用戶羣：

相關鏈接

[1] KubeVela

https://kubevela.net/

[2] Helm/Kustomzie 應用管理、多集羣應用交付

https://www.infoq.cn/article/sbwSX8ypxgID2-SB723K

[3] Terraform Controller 項目

https://github.com/kubevela/terraform-controller

[4] CUE 配置語言

https://cuelang.org/

[5] VelaD

https://github.com/kubevela/velad

點擊此處查看 KubeVela項目官網