作者 | Infoq Tina
背景
12 月 9 日，在 2021 年 KubeCon 云原生技術峰會上，CNCF 開源專案 KubeVela 宣布推出了 1.2 版本，
KubeVela 是一個簡單易用且高度可擴展的應用交付和管理平臺，基于 Kubernetes 與 OAM 技術構建，其核心功能是讓開發人員方便快捷地在 Kubernetes 上定義與交付現代微服務應用，而無需了解任何 Kubernetes 本身相關的細節， KubeVela 于 2020 年 11 月開源，2021 年 4 月發布 1.0 版本，
2021 年 7 月，KubeVela 和 OAM 專案整體捐贈給 CNCF 基金會托管， 在 1.2 版本中，KubeVela 新增了以應用為中心的控制面板 UI 功能，使應用組裝、分發、交付流程變得更簡單，并可以通過 UI 控制臺及時了解整個交付鏈路狀態，簡化多云/混合環境交付方式，另外還新增了基于訂閱模型的開源應用交付系統 ，使企業和云原生應用開發者只需要在 GitHub/Gitlab 上修改代碼，就可以自動完成云原生應用交付的整個鏈路， 從開源到現在已經有一年多，KubeVela 社區取得了什么樣的進展？有了哪些落地實踐？1.2 版本中為什么會新增加這兩個功能，適合于什么場景？
為解答這些問題，InfoQ 采訪了 OAM/KubeVela 產品和開源社區負責人曾慶國，
嘉賓簡介：曾慶國（花名：悅達），阿里云技術專家，目前負責 OAM/KubeVela 產品和開源社區，從事云原生、應用交付、開源領域研究和實踐多年，致力于推動云原生應用標準化和云原生技術“親民化”，
專訪問答
InfoQ：目前基于 Kubernetes 的云原生應用交付還存在哪些挑戰和難點？業界對應的有哪些解決方案？
曾慶國：如今 Kubernetes 逐漸成為了基礎設施的標準集成界面，云原生生態的繁榮也為我們提供了近乎無限的基礎設施能力，然而眾多的選擇是禮物，也是研發工程師的噩夢，大量復雜的知識需要學習，就好比一個業務研發工程師需要了解作業系統底層的系統呼叫一樣，然而應用的高效、安全交付，才是工程師真正的訴求，如何用好云原生繁榮的技術生態，又能降低用戶的使用門檻，同時安全可靠的交付應用，成為了業界新的挑戰， 業界的典型做法主要分為三類，一類是容器平臺模式，原汁原味的透出底層組件，靈活性很強，但平臺使用者需要學習組件大量的技術細節；第二類是在針對不同的業務場景構建內部的平臺，但是由于頂層設計不足，拉通難度大，不同垂直場景成為互相獨立的煙囪而無法做到能力復用、統一管理；第三類則是基于 CI/CD 系統，以腳本、配置等構建簡單的抽象體系簡化使用，這個方式的問題在于無法滿足大規模場景的需要，腳本和組態檔散落各處，其上手和維護的門檻非常高，也有安全隱患，
InfoQ：KubeVela 在 Kubernetes 生態系統中處于什么位置？初心是解決什么樣的問題？現在的目標與最初相比有所變化？
曾慶國：今天，無論是 Kubernetes 本身還是現有的各類應用交付系統，都缺乏一個統一的面向應用交付程序的上層抽象，這種缺乏往往同底層基礎設施緊密耦合，導致用戶心智負擔很重并且嚴重依賴于用戶個人的經驗和能力，這不僅會大幅影響用戶體驗、降低生產效率，甚至還會導致錯誤和故障的發生，KubeVela 是針對這個問題的開源、標準又不失靈活度的解法， KubeVela 在 Kubernetes 生態系統上層建立了“以應用為中心”的視角，業務層的開發者可以直接使用 KubeVela 作為開箱即用的 CI/CD 工具對接包括 Kubernetes 和云資源，完成應用交付和管理，對于中大型的公司，KubeVela 是一個具備充分可擴展性的應用交付和管理引擎，這些公司可以基于 KubeVela 標準化的擴展機制，針對自身業務場景擴展應用交付能力，快速構建自己的應用管理平臺， 這個初心一直沒有變化，我們從應用標準 OAM 到如今 KubeVela v1.2 即將推出的 UI 控制臺，這一系列的作業都是在推動云原生社區從基礎設施向應用層不斷發展和演進，最終實作開發者自助的應用交付和管理模式，最終期望為業界帶來標準和統一的云原生應用管理層，貧訓云計算的開發者，
InfoQ：從中立客觀的角度來講，您們認為 PaaS 解決方案和 KubeVela 各有什么樣的優缺點？
曾慶國：說到經典的 PaaS 解決方案，業界最出名的就是 Heroku 和 Cloud Foundry，它們提供完整的應用程式部署和管理功能，為業務開發人員提供了非常好的體驗和開發效率，但是云原生的崛起帶來了技術的全面升級，也帶來了云計算的巨大繁榮，傳統的 PaaS 平臺通過提供一層應用封裝和抽象為用戶帶來好的體驗，但這層封裝往往缺少良好的定制化擴展能力，平臺演進不得不完全依靠平臺團隊開發，無法應對業務新的個性化需求，無法應對新技術發展的敏捷集成，
KubeVela 和它們最大的區別在于其可擴展性，KubeVela 從設計的第一天就以高可擴展為原則，以此為核心提供端到端的抽象和用戶體驗，它的交付作業流乃至整個應用交付與管理能力集都是由獨立的可插拔模塊構成的，這些模塊可以隨時通過撰寫 IaC 配置模板的方式進行增減、重定義，且變更會即時生效，借助這種從核心模型到 UI 呈現都能夠快速變更的技術，使得 KubeVela 能夠兼顧“使用簡單”和“技術先進性”，
此外，KubeVela 是一個獨立于運行時集群的應用交付控制平面，天然支持多集群、多云混合環境（這是我們認為的下一代 PaaS 系統的合理形態），而現有的 PaaS 則往往選擇以插件形式部署在運行時集群當中，
InfoQ：基于 Helm 的應用交付方案，和 KubeVela 解決方案相比，兩者有哪些不同？
曾慶國：Helm 是 Kubernetes 的包管理器，它能夠以 Chart 為一個單元，提供打包、安裝和升級的一組 YAML 檔案的能力，
KubeVela 是一個完整的應用交付系統，它借助擴展能力可以部署各種制品型別，當然也包括 Helm Chart，除此之外還包括 Kustomize、Terraform Modules 等，KubeVela 支持 Kubernetes 和云服務等多種運行平臺，同時它也涵蓋了多集群交付的能力，包括跨環境部署的各類編排能力，例如，你可以使用 KubeVela 定義一個由 WordPress Chart 和阿里云 RDS 實體組成的應用，編排這兩個組件之間的順序關系，然后將它們按照一定的策略分發到多個 Kubernetes 集群當中，
我們也在社區里見到了一些基于傳統 CI/CD 工具 和 Helm 做應用部署的解決方案，這類方案通常會通過類似 Jenkins/Gitlab 這樣的 Pipeline ，將應用制品打包成 Helm Chart，然后直接部署到 Kubernetes 集群中，這種模式看似簡單，實際上存在三個方面的問題：
手工維護作業量大，比如由于突發的網路原因、或者由于 pipeline 系統的某個故障，就會中斷所有的發布并且需要人工介入，缺乏自愈能力，一旦場景有變化，就要修改腳本，比較難維護，
沒有一個統一的模型描述完整的應用交付程序，不同的人可以從多處入口對系統進行變更，例如有的通過 CI/CD 系統，有的直接改 Kubernetes，時間久了系統的配置會出現很大的不一致，容易引發故障，
存在安全風險，CI/CD 安全域不隔離，基礎設施多個集群的秘鑰全都在 CI/CD 系統中存盤，一旦被黑客突破容易引發非常大的系統安全風險，
KubeVela 是面向終態的應用交付和管理控制平面，KubeVela 的交付引擎具備自愈、冪等、收斂以及確定這四大特性，同時 KubeVela 背后有一個完整的應用模型（OAM），這個可以作為統一的應用入口，避免配置漂移等問題，KubeVela 自身也具備完整的 GitOps 以及多集群自治的功能，可以保證環境獨立管理，安全域隔離，
InfoQ：社區針對小規模集群或個人開發者的場景有所疑問，認為無論是增加 API 層還是還需編碼，KubeVela 的方向在復雜化應用交付和集群管理，對此您們有何看法？
曾慶國：KubeVela 從一開始就誕生于開源社區，演進至今已有上百位貢獻者參與代碼貢獻，吸納了來自阿里、騰訊、位元組、第四范式、Gitlab 等一系列不同領域公司的工程實踐，KubeVela 從一開始的設計目標是保證充分的可擴展性，這樣才能滿足用戶的多樣化場景需求，充分利用云原生領域百花齊放的技術生態紅利，
對于個人開發者或中小型科技企業，他們的實際需求必然是希望使用云原生技術就像使用 iOS 作業系統一樣，低門檻，易用且好用，把端到端的體驗做成倍訓才能更好滿足他們，無論增加 API 層還是需要編碼，都不是這類用戶想要關心的話題，
客觀的說，在 KubeVela 最初的幾個版本，由于要把面向可擴展性的核心設計做實，用戶看到的形態更多是偏框架一層的實作，在發展到 v1.1 版本以后，我們就陸續加入了很多端到端的集成案例，包括 GitOps、Jenkins CI/CD、Helm 包的完整部署等，即將發布的 v1.2 就更是一個面向小規模集群和個人開發者直接開箱即用的平臺了，用戶可以直接操作 KubeVela 的 UI 控制臺就可以完成應用交付的完整體驗，
InfoQ：1.2 版本中，基于訂閱模型的應用交付主要是解決什么場景下的問題？
曾慶國：基于訂閱模型的應用交付主要解決以下幾個維度問題：
1、區域隔離，安全自治
完整的應用交付鏈條分為 CI 程序、配置程序和部署程序，在訂閱模型中，控制平臺支持自動從制品庫發現制品的變更，從配置倉庫發現配置的變更，從而執行后續的部署動作，Runtime 集群區域主動從管控平臺獲取到部署任務執行，每一個環節都獨立作業，自成體系，每一個環節都根據需要進行授權和審核，安全可靠，
2、網路隔離，云邊協同
訂閱模型采用 PULL 的模式，僅需要單向通信網路即可作業，在邊緣應用交付中這是一個必需的選項，KubeVela 可以統一編排和管理云端和邊緣端應用，實作云邊協同，
3、集中管理，充分自動化
剛才我們提到，每一個階段都是獨立自動化作業的，且具備自愈、冪等、收斂以及確定這四大特性，讓我們的管理側實作統一， 另一方面，在 KubeVela 1.2 版本中，主要打造了在多集群、多環境下微服務應用的統一管理解決方案，用戶通過操作 UI 控制臺，實作集群接入、租戶分配、環境規劃和應用交付等完整用戶故事，
InfoQ：目前 KubeVela 社區發展情況如何？未來的路徑規劃是什么？
曾慶國：KubeVela 是一個從第一天就誕生在云原生社區的開源專案，KubeVela 背后的應用模型就是 OAM，自 2019 年阿里和微軟發布 OAM 模型以來，OAM 模型以及 KubeVela 專案已被阿里、Oracle、Salesforce、騰訊、位元組跳動、網易游戲等 40+ 家不同行業的領先企業應用在實際生產環境，幫助他們在不同場景下實作更高效的云原生應用的交付和管理，
展望
KubeVela 專案發展也非常迅速，至今已經累計有上百位開發者參與貢獻，社區有上百萬的鏡像下載，2021 年 7 月，KubeVela 和 OAM 專案也已經整體捐贈給 CNCF 基金會托管，所以這也是一個完全中立的社區，KubeVela 在社區用戶中的大規模實踐，也正在促進 OAM 成為混合云/多云/分布式云領域應用交付的事實標準，并在阿里、微軟、Oracle Cloud、騰訊等多家國內外廠商中被采用，2021 年 5 月，以 OAM 模型為核心的《云計算開放應用架構》標準檔案也已經由阿里云和信通院等 10 余家單位聯合發起并在“云原生產業大會”現場發布，
隨著 v1.2 版本的發布， 未來 KubeVela 將更多的提供端到端的完整用戶體驗，豐富更多垂直場景下的能力，朝著開發者能夠自助完成應用交付的方向演進，讓混合環境下的應用交付就像我們今天使用 App Store 一樣簡單，
您可以通過如下材料了解更多關于 KubeVela 以及 OAM 專案的細節：
專案代碼庫：github.com/oam-dev/kubevela 歡迎 Star/Watch/Fork！
專案官方主頁與檔案：kubevela.io ，從 1.1 版本開始，已提供中文、英文檔案，更多語言檔案歡迎開發者進行翻譯，
專案釘釘群：23310022；Slack：CNCF #kubevela Channel
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/449729.html
標籤：其他
下一篇：大資料資源管理方案研究