簡介：時間來到 2022 年，KubeVela 也正式進入了第四個階段，在原先核心控制器 API 基本穩定的基礎上，我們以插件的形式增加了一系列開箱即用的功能。讓開發者可以通過 UI 控制台的方式，連接配接 CI/CD 完整流程，端到端釋出多叢集應用，進一步提升開發者體驗。
作者：KubeVela 社群
随着雲原生的不斷發展和成熟，越來越多的基礎設施能力逐漸标準化成為 PaaS 平台或者 SaaS 化産品。一個産品的誕生不再像過去那樣需要建立一個團隊，從開發、測試一直到運維、基礎設施全部分多種角色系統完成。如今，靈活組織文化和雲原生技術驅動，使得這些職責更多的是“左移”到了開發者身上，測試左移、監控左移、安全左移，以及 DevOps 等一系列理念都是在強調，通過開源項目或者雲的産品和服務将測試、監控、安全、運維等一系列事務提前到開發階段完成。這看似美好的願景卻給開發者帶來了巨大的挑戰，開發者對底層五花八門的産品和複雜 API 缺乏掌控力，他們不僅僅是在做選擇，更多的需要去了解和協調底層複雜異構的基礎設施能力，以便滿足上層業務的快速發展和疊代需求。
這種複雜性和不确定性無疑大大降低了開發者的體驗，降低了業務系統的傳遞效率，增加了運維風險。開發者體驗的核心是“簡單”和“高效率”，不管是開發者還是企業都需要更好用的開發者工具或者平台來達成。在現代雲原生技術之上打造一款幫助開發者從開發、傳遞以及後續持續運維的一體化平台，一直是 KubeVela 演進的核心目标。如圖 1 所示，在 v1.2 版本中，我們圍繞開發者體驗新增了 UI 控制台元件（VelaUX），簡化了編排 YAML 的複雜性，完善了插件體系建設，豐富了雲資源的擴充能力，增加了大量 CI/CD 等生态對接的能力，進一步完善了開發者端到端的使用體驗。
發展曆程回顧
讓我們再來簡單回顧一下 OAM 和 KubeVela 的發展階段和曆程：
- OAM（Open Application Model）誕生和成長
在複雜的世界中要創造簡單，首先我們需要解決的問題就是抽象和标準化。阿裡雲和微軟聯合推出 OAM 模型，創新性地提出“關注點分離”的理念，開發者關注業務本身、運維關注子產品化能力。OAM 模型圍繞“一切皆服務，全面子產品化”的思想，為各大廠商和雲原生的平台建構者們實作自己的應用管理平台提供了簡單易用與高度可擴充相結合的标準實踐方式。該模型提出後的短短一年内便得到了包括 AWS、Oracle、騰訊、華為在内的國内外各大廠商響應，被國家信通院立項作為行業标準。因為大家有共同的目标，降低雲原生的使用門檻，讓應用傳遞和管理更簡單。
- KubeVela 開源項目 v1.0 釋出，為社群帶來了 OAM 的标準實作
有了 OAM 模型作為實踐指導，社群進階玩家也開始創造自己的工具來實踐，包括阿裡、微軟、Oracle、Upbond、騰訊在内的一系列公司都基于 OAM 的指導建構了自己的業務平台。但對于更廣大的開發者和中小型企業群體來說，他們卻無法直接享受模型帶來的紅利，于是，KubeVela 作為 OAM 社群的官方實作引擎誕生了。它從一開始就由 7 家來自不同組織的 OAM 社群成員從零到一建構。KubeVela 的實作吸收了多家公司針對 OAM 的實踐經驗，同時結合 Kubernetes 社群生态優勢，實作了自動化、可收斂、幂等且穩定的應用釋出控制器，圍繞 IaC（基礎設施即配置）構造了使用者友好的抽象層，幫助開發者實作了開箱基于的 OAM 實作引擎。
- KubeVela v1.1 釋出，實作應用傳遞工作流，原生支援混合環境多叢集應用傳遞
随着企業上雲程序的推進，混合雲、分布式雲等多元化基礎設施逐漸成為常态。KubeVela 作為現代應用管理系統也順應潮流，整體架構更新為面向混合環境做應用傳遞和管理的控制平面，将所有的功能天然構築在多叢集技術之上。我們相信，出于高可用、成本性能、資料安全等多方面因素，未來大多數企業應用的形态都将是異構多元的。KubeVela v1.1 版本的釋出，同時也實作了高度可擴充的應用釋出工作流，它天然以混合環境架構呈現，創新性的實作了傳遞工作流與應用抽象相結合的工作模式，實作了面向終态的應用傳遞工作流，大大簡化了流程編排的複雜性。
時間來到 2022 年，KubeVela 也正式進入了第四個階段，在原先核心控制器 API 基本穩定的基礎上，我們以插件的形式增加了一系列開箱即用的功能。讓開發者可以通過 UI 控制台的方式，連接配接 CI/CD 完整流程，端到端釋出多叢集應用，進一步提升開發者體驗。
v1.2 版本的核心能力
圖形化操作控制台（VelaUX）
提供好用的圖形化操作界面是降低開發者使用門檻的首選途徑，從 KubeVela 誕生以來，社群對 UI 控制台的呼聲一直很高。從 v1.2 版本開始，它正式到來了。打造 UI 控制台的目的是幫助開發者以更标準化的方式組裝和管理異構業務應用，幫助他們分析和更快的發現業務故障和阻礙。
VelaUX[1] 是 KubeVela 的前端項目，設計實作時它充分考慮了 KubeVela 的可擴充性這一核心要點。引入了低代碼平台的理念來打造前端，我們的目标是打造一個可以通過拖拉拽方式就能做到自定義應用傳遞輸入參數，并且實作運作資料可觀測的平台。為此我們設計了前端描述規範（UISchema[2]），配合 KubeVela 的子產品化定義（X-Definition[3]），通過配置就可以渲染出豐富的前端互動元素。同時為了讓前端的資料查詢也配置化，我們設計了多元資料自定義查詢語言（VelaQL[4]），這樣的設計形成了 KubeVela 傳遞和管理異構應用的基礎。
目前通過 VelaUX ，使用者可以管理擴充，連接配接 Kubernetes 叢集，配置設定傳遞目标，規劃環境和傳遞各類型應用，并觀測應用運作狀态，實作應用傳遞的完整閉環。
圖 2：VelaUX 預覽
如圖 2 所示，VelaUX 中出現了一些新名詞，請參考核心概念[5]文檔進行學習和了解。
多環境統一化管理
KubeVela 将 N 個Kubernetes 叢集，N 個雲廠商服務或其他私有雲服務統一為大的基礎設施資源池。在此基礎上，我們的開發者可以按照業務需求、流程需求、團隊需求等多種業務次元劃分環境。在大資源池的基礎上形成環境空間。同一個應用可釋出到不同的環境，環境之間從管理到運作态完全隔離。
圖 3：多環境/多叢集應用管理頁面
如圖 3 所示，應用可被釋出到生産、測試、預設三個環境中，每一個環境可以包括多個傳遞目标，每一個傳遞目标背後可以是獨立的 Kubernetes 叢集。
異構應用标準化傳遞
在雲原生體系中，我們傳遞應用的形式選擇非常多。基于 Kubernetes 基礎設施，我們既可以通過成熟的 Helm Chart 包傳遞中間件和第三方開源應用，也可以通過鏡像傳遞企業業務應用，還可以通過 OpenYurt 傳遞管理邊緣應用。基于雲服務商的開放能力，我們可以傳遞資料庫、消息、緩存等中間件，也有日志、應用監控等運維能力。
對于這麼多的可選項，KubeVela 采用标準的 OAM 規範實作對異構應用的統一傳遞和管理。KubeVela 實作了高度可擴充的傳遞系統，通過内置、社群共享等形态幫助使用者擴充平台，以一緻化的傳遞和管理體驗處理異構的應用。在 KubeVela 之上，開發者看到的都是子產品化、一切皆服務的管理形态。
圖 4：雲服務應用管理頁面
如圖 4 所示，我們可以看到，相同的應用管理頁面，使用者可以非常便捷得擷取到雲服務應用。開發者可以通過閱讀下面幾篇文檔檢視異構應用的傳遞過程：
- 傳遞 Docker 鏡像[6]
- 傳遞 Helm Chart 包[7]
- 傳遞 Kubernetes 資源[8]
- 傳遞 雲服務[9]
擴充體系（Addon）
KubeVela 從一開始就是設計為一款微核心高可擴充的系統，上文我們說到異構應用，KubeVela 可以通過擴充體系，以标準化的形态，擴充無限的應用傳遞能力。既比對企業差異性訴求，也不帶來過多的認知負擔。KubeVela 中可擴充的點包括了元件類型、運維能力、工作流類型、應用傳遞政策等。在目前版本中，我們釋出了 Addon 擴充體系。Addon 是組織各種擴充能力的承載體，它便于分發和管理。
圖 5：KubeVela 插件管理頁面
目前在官方倉庫中已經存在如圖 5 所示的可用 Addon。同時在實驗性倉庫中我們正在聯合社群使用者積極創造更多的擴充能力。當然，這裡需要每一個社群開發者的積極參與。
截止到現在，KubeVela 已經成長為一款可直接服務于廣大開發者的應用傳遞平台，那麼企業哪些場景可以直接利用 KubeVela 呢？我們整理了以下幾個常見場景：
企業開發場景解決方案
多叢集應用 DevOps
在過往社群的交流中，我們發現企業主流的研發體系都類似如圖 6 所示的結構，他們使用雲服務廠商提供的計算資源作為生産、示範環境。使用自己購買或曆史遺留的伺服器搭建開發、測試環境。如果業務有多區域或災備需求，生産環境可能需要部署到多個區域或多雲。
圖 6：多叢集應用實踐架構
對于基礎的 DevOps 流程，包括了代碼托管和 CI/CD 的環節。KubeVela 目前為你提供 CD 環節的支援。對于企業實踐的步驟如下：
- 根據實際情況準備本地或雲服務資源。至少單項打通本地和雲資源的網絡，便于資源集中管理。
- 将 KubeVela 系統搭建在生産環境中，保障持續的可用性。
- 通過 KubeVela 部署 Gitlab、Jenkins、Sonar 等 DevOps 工具，并打通工具鍊。通常情況下，代碼托管和開發工具的可用性至關重要，我們需要将其部署在生産環境中（如果你本地機房具備生産可用性，且希望代碼資料在本地環境流轉，可部署在本地機房）。
- 通過 KubeVela 規劃本地開發環境，部署本地測試用中間件，規劃生産環境和部署雲服務中間件。
- 通過 Jenkins 搭建業務代碼 CI 流水線，産出 Docker 鏡像交由 KubeVela 進行多環境部署，形成完整應用傳遞工作流。
結合 KubeVela 的多叢集應用 DevOps 方案有如下優勢：
（1）開發者無需掌握過多的 Kubernetes 生态知識，可實作異構應用雲原生部署。
（2）多叢集，多環境統一管理，原生可部署跨叢集應用。
（3）統一的應用管理模式，無論是業務應用還是開發工具鍊。
（4）靈活的工作流，幫助企業打通各種開發規範流程。
混合環境一體化管理
不同的企業往往都存在不一樣的基礎設施和業務訴求。在基礎設施側：企業可能搭建了私有雲，可能購買了公有雲，可能還有邊緣計算資源。在業務側：不同的業務規模不同，資源需求不同，可能有多雲多活應用，也有企業遺留系統。在研發側：業務研發往往需要開發、測試、預發和生産環境。在管理側：不同的業務團隊需要互相隔離，又可能需要業務互通。
随着時間的累積，企業由于職責邊界和不同分工的影響，會逐漸形成不同業務團隊互相獨立甚至割裂的狀态，這種割裂包括了：開發工具割裂，技術架構割裂，業務管理形态割裂。KubeVela 秉持着“尊重制實，積極創新”的原則，帶來的方案是追求統一的過程中用高擴充的能力去相容差異性。
- 面對基礎設施差異，我們支援以 Kubernetes API、雲服務 API 或其他自定義 API 的形态，去對基礎設施進行充分的模型化。最終通過統一的 OAM 模型向上暴露一緻的概念。
- 面對業務架構差異，應用模型是開放的，對架構無要求的。KubeVela 做的是連接配接和賦能，連接配接已有系統，通過擴充機制加持新的生态技術。
- 面對開發工具鍊的差異，企業中可能已經存在不同的開發工具鍊，産出不同的業務制品。KubeVela 通過擴充和标準模型去支援各類制品，實作其标準化傳遞。當然，它的标準逐漸衍生到前置環節，幫助企業逐漸實作工具鍊一緻化。是以，你不用擔心你是用的 Gitlab 還是 Jenkins，它都能對接。
- 面對運維能力差異，企業中不同團隊的運維能力、工具方案可以在 KubeVela 的規範下逐漸積累，能力互通。更多運維能力也同樣在社群的次元進行共享和複用。
是以，使用 KubeVela 來作為企業打通業務，進行統一能力建設的基礎平台，它是可落地、有未來的方案。
自定義企業釋出平台
從 Heroku 、Cloud Foundry 時代開始，市場上一直在産生不同的 PaaS 平台，我們都知道固定模式的釋出平台往往不适合所有的企業。舉個例子，某些規範化程度較高的企業，他們基于業務的特性，釋出應用時僅需更新鏡像名稱，然而使用通用 PaaS 就不得不去了解大量的概念和參數。再比如某個企業生産的是 AI 應用，對于 AI 應用的釋出與普通應用有比較大的差別，這時就需要定制 AI 場景的 PaaS，企業不得不付更多的費用和學習更多的概念。
通用産品不符合企業需求時，自研是真實存在的訴求。但是對于從零開始自研平台，必然又需要投入大量的人力物力，甚至超過了企業核心業務的投入，這顯得得不償失。KubeVela 也考慮到了具備自研能力企業的獨特訴求，他們可以基于 KubeVela 微核心、高可擴充的設計，針對自己的業務場景和領域知識，打造屬于自己的、更為簡單易用的業務平台。
對于需要自研釋出平台的企業來說，KubeVela 的微核心是一個 PaaS 平台研發架構。一方面，企業可以根據自己的需求自研或者安裝社群的各種功能插件；另一方面，企業也可以基于 OAM 模型修改子產品化配置，新增或裁剪使用者使用的參數。這種子產品化的設計可以大大降低企業的投入成本，同時可以跟上社群的發展潮流，随時将社群更多的先進技術轉化為自身的生産力。
參與社群
做了這麼多的介紹，你是否對 KubeVela 的發展有了一些新的認識，沒有哪個産品是絕對的銀彈，也沒有一個方案可以解決所有的問題。但是我們的理想是可以創造一個标準化模式，讓更多的企業和開發者使用者參與到這場為了“簡單”和“高效”的開發者體驗戰役中來。KubeVela 還很年輕，我們希望你可以參與進來共同打造。這裡非常感謝在過去參與 KubeVela 貢獻的 100 多位開發者[10]，正是因為你們的攜手努力，才讓我們的社群生态變得更加繁榮。
共建 OAM 應用規範
對于 OAM 應用規範，模型的更新和更新基于 KubeVela 實踐驅動，但是它并不綁定 KubeVela 實作。它是 KubeVela 在雲原生應用傳遞和管理層面實踐經驗的總結和抽象，是創造規範化應用管理體系的最佳實踐和核心理念。我們非常歡迎雲廠商、平台廠商、最終使用者可以參與進來，同時我們也欣喜的看到國内包括騰訊在内的多家廠商對 OAM 應用規範的關注和支援。任何人、組織都可以發表你的想法、建議和思考。
參與 OAM 模型讨論：
共建 Addon 擴充生态
如上文介紹的一樣，我們已經開啟了 Addon 的擴充體系，非常歡迎社群的創造者、開發者可以來貢獻更多的擴充能力。
如何擴充和貢獻 Addon 參考文檔：
貢獻雲服務能力
KubeVela 通過內建 Terraform Module 來擴充雲服務內建能力，我們已經支援了常用的雲資源[11] ，歡迎社群朋友參考并貢獻更多的雲服務廠商和産品。
如何擴充和貢獻雲資源 參考文檔：
回報你的需求或痛點
或許你是普通開發者，也或許你是雲原生領域的從業者，如果你認可我們的方向，認可我們正在做的事情，我們非常歡迎你可以參與到 KubeVela 社群讨論中來。
社群讨論：
KubeVela 網站加速通路
KubeVela 的官方文檔托管在 GitHub （ ）上，如果你發現有任何錯漏或者想要參與翻譯，歡迎直接到項目中貢獻。同時為了國内使用者可以加速通路，我們增加了 kubevela.net 這個域名，可以友善國内使用者更快的通路，内容與 kubevela.io 的域名完全一緻、實時同步。
KubeVela 是 CNCF 沙箱項目，了解更多資訊，請點選此處查閱官方文檔。
相關連結
[1] VelaUX：
https://github.com/oam-dev/velaux
[2] UISchema：
https://kubevela.io/zh/docs/reference/ui-schema
[3] X-Definition：
https://kubevela.net/zh/docs/platform-engineers/oam/x-definition
[4] VelaQL：
https://kubevela.io/zh/docs/platform-engineers/system-operation/velaql
[5] 核心概念：
https://kubevela.net/zh/docs/getting-started/core-concept
[6] 傳遞 Docker 鏡像：
https://kubevela.net/zh/docs/tutorials/webservice
[7] 傳遞 Helm Chart 包：
https://kubevela.net/zh/docs/tutorials/helm
[8] 傳遞 Kubernetes 資源：
https://kubevela.net/zh/docs/tutorials/k8s-object
[9] 傳遞雲服務：
https://kubevela.net/zh/docs/tutorials/consume-cloud-services
[10] 100 多位開發者：
https://github.com/oam-dev/kubevela/graphs/contributors
[11] 常用的雲資源：
https://kubevela.io/zh/docs/end-user/components/cloud-services/provider-and-consume-cloud-services#支援的雲資源清單
原文連結：301 Moved Permanently
本文為阿裡雲原創内容，未經允許不得轉載。